Validation of meta.yaml in cross-org repos#3680
Conversation
|
I can see some CI failures when the YAML schema can't be found. Would I check whether |
mirpedrol
left a comment
There was a problem hiding this comment.
Could we add a test where we try to lint a module from the nf-core-test repository https://github.com/nf-core-test/modules.git? Thanks!
|
Hi again, I could do some tests, the issue is that you have to provide the git remote in the linting command, like |
I can confirm it works for subworkflows (I still need to check modules). But I'm still wondering: why is nf-core making a git clone of the remote of the current repository instead of simply using the existing checkout that the user is trying to lint ? |
|
If i understand it correctly, we use this setup to handle multiple remote repositories correctly, so it always compares against the correct one |
6b80db2 to
924721a
Compare
924721a to
ae7ca23
Compare
|
Alright. I've now removed that part of the change. |
Codecov Report✅ All modified and coverable lines are covered by tests. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
We're making our way towards setting up our cross-organisation repository for modules and sub-workflows.
Linting is now failing and here is what I propose to change:
git_remotekey under component names: https://nf-co.re/docs/tutorials/external_usage/cross_organisational_subworkflowsThe problem is that
nf-core lintuses~/.config/nfcore/nf-core/modules/subworkflows/yaml-schema.jsonwhich is not aware of the possibility of that extra key. I therefore propose to use the JSON that is shipped in the user repository itselfsubworkflow.base_dir. For consistency, I make modules linting usemodule.base_dir.This change in fact gives modules repo owners the liberty of defining their own yaml validation rules.
meta_yaml["components"]can now contain dictionaries, it needs a bit of parsing to get the component namesBest,
Matthieu
PR checklist
CHANGELOG.mdis updateddocsis updated