@nf-core-bot changelog

@ewels Thanks for creating the pull request! This fixed the issue for me.
However, it will make resuming/caching of downstream processes (multiqc) also impossible, right?

However, it will make resuming/caching of downstream processes (multiqc) also impossible, right?

Yes - It will make any consumers of the ch_collated_versions channel, or processes downstream of those have their cache broken every time.

Generally there aren't any processes downstream of MultiQC, it's typically used as a final step that summarises the run, but you're right that it is something that we should be intentional about. I think that we used to have the cache disabled for MultiQC anyway, but I can't find that config now so maybe it was dropped. I'll raise this in Slack on the #tools channel.

@ewels does this also fix #3110?

Or does it make it worse? 😱

It makes it worse..

Why not make it a native process?

I'm assuming this will be greatly improved by usage of topics and workflow output

Something I just discovered in my own pipeline, but many pipelines make use of .first() to take the first copy of the versions.yml. The versions.yml that gets selected out of say 5 runs of the same process though is not always the same. This means the path to the versions.yml may change, and so the input set will change preventing caching too.

I have found that in my resumed pipeline the software versions yaml just simply isn't being updated at all. I'm not sure if this is related to the bug/behaviour that this PR addresses, but leaving comment here so it's noted somewhere.