Add test for initialize breaking the template

[edmundmiller]

If we're moving stuff out of the template that can break the template we need to check for changes.

Can include any other files that might break the template as well.

[edmundmiller]

I have no idea how the CI for that works in tools @nf-core/infrastructure 😬 looks like I need some template files but I can't find those.

[adamrtalbot]

Sorry, not sure I understand what this is for?

Is this so when you create a pipeline the modules/subworkflows components haven't messed up the default running?

[edmundmiller]

https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-using-an-action-in-the-same-repository-as-the-workflow

[edmundmiller]

Is this so when you create a pipeline the modules/subworkflows components haven't messed up the default running?

Exactly!

Scenario: PR to this breaks the template. There's no check. It breaks tools but doesn't get discovered for a week. Then @nf-core/infrastructure has to go back and figure out the murder mystery.

[adamrtalbot]

Hmmm can we approach this in a better way? It's hideously convoluted to test a different repo within another repo.

• Firstly any subworkflow should be completely encapsulated and tested, so no errors within a subworkflow
• The subworkflow can be inserted without touching other components.
• When using the template, it pulls a specific version of the subworkflow, so we have to make a deliberate choice to update it.

That way, the tests can all be done on the nf-core/tools side.

Put another way, we should make it so there is no way updating a subworkflow or module breaks the template. This also applies to default modules like FASTQC and MultiQC.

[edmundmiller]

no way updating a subworkflow or module breaks the template

Love it, that's the goal!

It's hideously convoluted to test a different repo within another repo.

Yeah it's a bit much to think about.

How does tools currently install/update fastqc?

[mashehu]

How does tools currently install/update fastqc?

It's a manual step in the release process: https://github.com/nf-core/tools/blob/master/.github/RELEASE_CHECKLIST.md?plain=1#L6

[adamrtalbot]

It just copy + pastes it. It could actually be completely out of sync and we wouldn't know until tests in tools failed: https://github.com/nf-core/tools/tree/dev/nf_core/pipeline-template/modules/nf-core/fastqc

[edmundmiller]

Via @mashehu -bot nf-core/tools@8d1094c

So we'd catch it there, might just go a few months without noticing, or be something that breaks when the dependancies get bumped before release and stales it.

Maybe a cron job that runs the module and subworkflow update and bumps it in modules so it can get fixed ahead of time and not block a release?

[adamrtalbot]

(regarding copy + pasting the module)

Which is a pretty good choice - simpler is better.

[mashehu]

Maybe a cron job that runs the module and subworkflow update and bumps it in modules so it can get fixed ahead of time and not block a release?

couldn't renovate do this?

[edmundmiller]

couldn't renovate do this?

Probably, I think we debated it. But I think that's a whole thing to make a renovate datasource for nf-core/modules.

[mashehu]

closing this, because we will use nf-core/tools#2733 instead