Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

add fq lint #57

Draft
wants to merge 5 commits into
base: dev
Choose a base branch
from
Draft

add fq lint #57

wants to merge 5 commits into from

Conversation

erkutilaslan
Copy link

@erkutilaslan erkutilaslan commented Oct 29, 2024 •
edited
Loading

added barebones fq/lint module to the pipeline.
looking for feedback to how to implement it.

PR checklist

  • This comment contains a description of changes (with reason).
  • If you've fixed a bug or added code that should be tested, add tests!
  • If you've added a new tool - have you followed the pipeline conventions in the contribution docs
  • If necessary, also make a PR on the nf-core/seqinspector branch on the nf-core/test-datasets repository.
  • Make sure your code lints (nf-core lint).
  • Ensure the test suite passes (nf-test test main.nf.test -profile test,docker).
  • Check for unexpected warnings in debug mode (nextflow run . -profile debug,test,docker --outdir <OUTDIR>).
  • Usage Documentation in docs/usage.md is updated.
  • Output Documentation in docs/output.md is updated.
  • CHANGELOG.md is updated.
  • README.md is updated (including new tool citations and authors/contributors).

@github-actions GitHub Actions
Copy link

github-actions bot commented Oct 29, 2024 •
edited
Loading

nf-core pipelines lint overall result: Passed ✅ ⚠️

Posted for pipeline commit 2b75934

+| ✅ 191 tests passed       |+
#| ❔   1 tests were ignored |#
!| ❗  21 tests had warnings |!

❗ Test warnings:

  • readme - README contains the placeholder zenodo.XXXXXXX. This should be replaced with the zenodo doi (after the first release).
  • pipeline_todos - TODO string in main.nf: Remove this line if you don't need a FASTA file
  • pipeline_todos - TODO string in nextflow.config: Specify your pipeline's command line flags
  • pipeline_todos - TODO string in nextflow.config: Optionally, you can add a pipeline-specific nf-core config at https://github.com/nf-core/configs
  • pipeline_todos - TODO string in README.md: TODO nf-core:
  • pipeline_todos - TODO string in README.md: Include a figure that guides the user through the major workflow steps. Many nf-core
  • pipeline_todos - TODO string in README.md: Fill in short bullet-pointed list of the default steps in the pipeline
  • pipeline_todos - TODO string in README.md: Add citation for pipeline after first release. Uncomment lines below and update Zenodo doi and badge at the top of this file.
  • pipeline_todos - TODO string in README.md: Add bibliography of tools and data used in your pipeline
  • pipeline_todos - TODO string in usage.md: Add documentation about anything specific to running your pipeline. For general topics, please point to (and add to) the main nf-core website.
  • pipeline_todos - TODO string in main.nf: Optionally add in-text citation tools to this list.
  • pipeline_todos - TODO string in main.nf: Optionally add bibliographic entries to this list.
  • pipeline_todos - TODO string in main.nf: Only uncomment below if logic in toolCitationText/toolBibliographyText has been filled!
  • pipeline_todos - TODO string in test_full.config: Specify the paths to your full test data ( on nf-core/test-datasets or directly in repositories, e.g. SRA)
  • pipeline_todos - TODO string in test_full.config: Give any required params for the test so that command line flags are not needed
  • pipeline_todos - TODO string in test.config: Specify the paths to your test data on nf-core/test-datasets
  • pipeline_todos - TODO string in test.config: Give any required params for the test so that command line flags are not needed
  • pipeline_todos - TODO string in base.config: Check the defaults for all processes
  • pipeline_todos - TODO string in base.config: Customise requirements for specific processes.
  • pipeline_todos - TODO string in methods_description_template.yml: #Update the HTML below to your preferred methods description, e.g. add publication citation for this pipeline
  • pipeline_todos - TODO string in awsfulltest.yml: You can customise AWS full pipeline tests as required

❔ Tests ignored:

  • files_unchanged - File ignored due to lint config: .github/CONTRIBUTING.md

✅ Tests passed:

Run details

  • nf-core/tools version 3.0.2
  • Run at 2024-10-30 11:17:23

@ctuni
Copy link

ctuni commented Oct 29, 2024 •
edited
Loading

I see that the fq tool by default exits with an error if linting issues are found. I think that the way of using it in the pipeline should be instead to use the --lint-mode log ext.args always. That way the errors are logged and the user can read them instead of having the pipeline fail and exit if issues are found in the validation of FASTQ files.

By adding this to the conf/modules.config:

    withName: FQ_LINT {
        ext.args = '--lint-mode log'
    }

@sarahjeeeze
Copy link

Do you need to update the README.md

MatthiasZepper
MatthiasZepper requested changes Oct 29, 2024
View reviewed changes
Copy link
Member

@MatthiasZepper MatthiasZepper left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot for your contribution!

Like with your other PR, you are missing a module config. Therefore, the tool lacks ext.args and a publishDir directive. Please see this example from the rnaseq pipline for inspiration - but disregard the complex conditional logic.

As a bare minimum, you should set the --lint-mode log as ext.args, otherwise the pipeline will crash upon encountering a single invalid read pair. Optionally, you can choose to pick a lower validation level by default.

I am somewhat undecided, whether the output should nonetheless be mixed into the MultiQC channel, although the tool is not supported.

@erkutilaslan
Copy link
Author

Thanks a lot for the comments and suggestions! I have a question regarding the publishDir.
The conf/modules.config contains the following:

    publishDir = [
        path: { "${params.outdir}/${task.process.tokenize(':')[-1].tokenize('_')[0].toLowerCase()}" },
        mode: params.publish_dir_mode,
        saveAs: { filename -> filename.equals('versions.yml') ? null : filename }
    ]

Which creates a publishDir for fq/lint output. Should I still define the publishDir for the module separately as suggested?
If so if someone can explain the logic of the above part I would be grateful :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@MatthiasZepper MatthiasZepper MatthiasZepper requested changes

Requested changes must be addressed to merge this pull request.

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@erkutilaslan @ctuni @sarahjeeeze @MatthiasZepper