Add READS assigned_accessions table into multiqc.report
Nobody has claimed this yet.
- Dominant language
- Nextflow
- Stars
- 18
- Forks
- 8
- PR merge metrics
- No merged PRs in 30d
Description
Difficulty: Medium
Why this matters: once a submission to ENA (European Nucleotide Archive) finishes, the pipeline builds a MultiQC report summarising the run. For metagenomic assemblies and MAGs/bins modes, that report includes two tables: one with the ENA accessions assigned to each record, and one with the metadata that got submitted for each record. Reads mode is missing both. The accessions data is actually already produced and passed to MultiQC, but assets/multiqc_config.yml has no matching entry telling MultiQC to render it as a table, so it's silently dropped. The metadata table doesn't exist at all yet for reads mode.
Some terms: ENA (European Nucleotide Archive) is the public repository this pipeline submits data to, and Webin is ENA's account and authentication system needed to submit anything (free, self-service registration). MultiQC is the tool that builds the summary report at the end of the run. MultiQC only turns a file into a custom table if multiqc_config.yml has a matching sp (search pattern) entry and a custom_data entry describing its columns, otherwise the file is ignored even if it reaches MultiQC.
Skills / experience: a contained, well scoped Nextflow and YAML config change, a good task for getting familiar with how a workflow feeds files into MultiQC. If nf-test is new to you, the nf-core nf-test testing guide is a good place to start, since you'll want to check both tables actually render in a test run.
Suggested approach:
- Read the
readsmode section ofdocs/usage.mdto refresh what fields are collected for a read entry, and checkdocs/output.mdfor how the multiqc report's contents are currently documented. - Run the pipeline in
readsmode locally and open the generated multiqc report to confirm what's missing, don't just trust the code, check the actual output. - In
assets/multiqc_config.yml, add aspandcustom_dataentry forreads_accessions.tsv, following the pattern ofsubmission_results_assemblies/submission_results_genomes, so the accessions table that's already being generated actually shows up. - Look at how
CREATE_ASSEMBLY_METADATA_CSVis used inworkflows/assemblysubmit.nf, both the module itself and itsassembly_metadataentry inmultiqc_config.yml, that's the pattern to copy for the metadata table. - Create a similar small module for reads mode that writes one row per read entry, using the fields that were actually submitted (things like
sample_accession,platform,library_source, etc.), wire it intoworkflows/readsubmit.nf, and add its ownsp/custom_dataentry inmultiqc_config.yml. - Update tests to check both tables actually appear in the report output, not just that the pipeline runs.
- Update
docs/output.mdif it documents what the multiqc report contains.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the reads section of docs/usage.md and docs/output.md, then run the pipeline in reads mode and inspect the generated MultiQC report. Read assets/multiqc_config.yml and compare submission_results_assemblies and assembly_metadata with workflows/assemblysubmit.nf; use workflows/readsubmit.nf and the existing module as entry points. Done means both reads accessions and metadata tables render in the report, tests cover them, and relevant output documentation is updated.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- yaml
- Domain
- devops, documentation
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 68/100