Automation for Zenodo DOI

Zenodo DOIs are an excellent way to cite nf-core pipelines, especially as they give a specific DOI per version of the pipeline. However, there are two points with the current setup which are quite annoying:

1. We (one of the nf-core admins) has to manually set up the automated GitHub link for each new pipeline
2. DOIs are given after a release. This means that the master branch then has to be updated to show the badge for the new DOI after the release is pushed. This changes the commit hash on master so that it no longer matches the release.
   • This is very slightly bad practice as we're no longer exactly the same as the release. But worse, it messes up functionality in nf-core list and elsewhere, which checks commit hashes of local clones to see if the latest release is being run.
   • Also bad - if people properly run the release (with the -r nextflow flag or by manually downloading), the bundled code cannot include any information about the proper DOI for citation. This will become more of an issue as we try to improve the ease of access to this information (see #361)

After a very, very quick skim read of the docs, I think that we should be able to solve both of these problems with what seems to be an excellent Zenodo API. I see two approaches:

Approach 1: Fully automate releases

• We can create new resources for new pipelines: https://developers.zenodo.org/#create
• We can reserve DOIs before publication. This can be done on the website and in the API (with the prereserve_doi flag), but not with the GitHub linkage.
• We can then update the code with the new Zenodo badge and any other references to the DOI, commit this, then trigger the GitHub release using the GitHub API.

The downside is this has to be done before the release. This means that we can't use the GitHub release web interface, but instead have to trigger the release programatically somehow. This probably needs a little though as to how to do it nicely. Also, whether it's worth it!

Approach 2: More manual DOI fetching, with lint checks

An alternative to this is that we can go fully the other way, and instead of using the automated linkage, manually pre-reserve the DOI on the Zenodo website before release. This would have to be done by the pipeline authors. We could potentially then get the lint tests to check for this when running with the --release flag to ensure that it happens properly.

Welcome for thoughts and feedback!

Phil

Start by reviewing the Zenodo API documentation for resource creation and DOI preregistration, then compare it with the GitHub release API and the proposed --release lint checks. The work is done when an agreed approach automates or validates DOI setup while preserving release commit hashes and making the DOI available in released pipeline code.