Repository navigation
nf-core pipelines lint silently suppresses all module linting on error. #4447
Description
Description of the bug
If you run nf-core pipelines lint on a pipeline which has anything in its module directory which causes module linting to fail then the module linting is totally suppressed from the output with no obvious indication it failed or why.
An easy example to trigger this is to remove the meta.yml from one of the nf-core modules in the pipeline.
pipelines lint: suppresses errormodules lint:FileNotFoundError: meta.yml not found at modules/nf-core/repeatmodeler/repeatmodeler/meta.yml
Other examples that can cause this:
- failed patch application
- error in any local module
Command used and terminal output
System information
No response
Activity
JulianFlesch commentedon Aug 20, 2026
Thanks for writing the issue!
I am working on it here: #4450
I could only find one instance so far where an issue with a module blocks the linting and it is exactly the one you describe and I addressed in the PR: If a module has no meta.yml the linter surfaced an exception instead of trying to proceed gracefully.
Do you have other examples?
awgymer commentedon Aug 20, 2026
Did you try breaking a local module?
For example split an output tuple across two lines and then run pipelines lint.
For the patch failure you need to make a patch that is outdated for the module and then try running the linting. This will cause the module to fail I believe.
JulianFlesch commentedon Aug 25, 2026
I tried to break local and nf-core modules of a pipeline (this was my test: https://github.com/JulianFlesch/rnaseq-fork) in various ways to check 👍
awgymer commentedon Aug 26, 2026
Urgh, I finally went through and traced everything through pipeline level linting and it turns out that there is just a kind of 'bug' between the subworkflows and modules linting handling.
Both sub-objects get their
lint_testsrestricted here but then in thesubworkflowslintinglint_testsis never used as a filter when linting local subworkflows like it is for local modules. This means that you get some linting warnings for subworkflows when the equivalent for local modules are suppressed.The linting code is a little bit spaghetti around this - I wrote a lot of the local-only bits in a hackathon a few years back and never looked at it since - and probably should be properly aligned.
This is sort of secondary to this issue, but it does explain why I thought some lint test failures were being suppressed by
pipelines lintand in reality they weren't -pipelines lintnever actually runs a bunch of them. So whilst I had 3/4 different errors that showed up once I ran the standalone component lints, the only one that actually runs and blocks onpipelines lintis indeed themeta_ymlcase.