Skip to content

Commit

Permalink
Merge pull request #62 from sanger-tol/release_instructions
Browse files Browse the repository at this point in the history
Release instructions
  • Loading branch information
muffato authored Mar 7, 2024
2 parents f960a39 + b06d63b commit af051a3
Show file tree
Hide file tree
Showing 5 changed files with 96 additions and 4 deletions.
2 changes: 1 addition & 1 deletion markdown/developers/modules.md
Original file line number Diff line number Diff line change
Expand Up @@ -38,7 +38,7 @@ Here is the decision tree you can use to decide whether to make a nf-core module
### Versioning

Assign a version to each script independently, the simplest scheme being to start with 1.0 and incrementing it each time you change the script.
To simplify maintenance of the script, the module, and the pipeline, we recommend implementing in each script a way of printing a short usage message and a version number. This will also help you remember what the script is for and what arguments to pass !
To simplify maintenance of the script, the module, and the pipeline, we recommend implementing in each script a way of printing a short usage message and a version number. This will also help you remember what the script is for and what arguments to pass!

Here is an example one-liner you can plug at the top of bash scripts

Expand Down
92 changes: 92 additions & 0 deletions markdown/developers/pipeline-release.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,92 @@
---
title: Pipeline Release Guidelines
subtitle: Guidelines on releasing a sanger-tol pipeline
---

## nf-core Release Checklist

This page is heavily inspired by the [nf-core release checklist](https://nf-co.re/docs/contributing/release_checklist).

## Branch model

First a reminder about how we use branches in sanger-tol:

- `main` is the release branch. Releases can only happen from the `main` branch and code present on the `main` branch _has_ to be released.
- `dev` is the staging branch. Code on the `dev` branch should always pass tests and be functional (this is a condition of our [review guidelines](/docs/contributing/review_checklist)). Releasing a pipeline involves merging `dev` into `main`.
- Feature branches are where development happens.

## Release steps

Follow the "Before you release" and "Steps to release" from the [nf-core release checklist](https://nf-co.re/docs/contributing/release_checklist) with the following adaptations:

1. Replace "nf-core" with "sanger-tol".
2. Since we develop directly off the sanger-tol repository, the version bump happens there, not "on your fork".
3. The "core team member" who can activate the integration with Zenodo is [@muffato](https://github.com/muffato).
4. We don't have Twitter integration.

About version numbers and release names:

1. The release _number_ is made of digits and dots **only**, and follows [Semantic Versioning](https://semver.org/).
2. The release _name_ is whatever you want. It can be Harry Potter, Stargate, or Pokemon. Express your creativity! You only need a new name for major and minor releases. Patch releases reuse the last name with the addition of `(patch ${PATCH_NUMBER})`.
3. The release _title_ you enter on GitHub must be of the form `v${RELEASE_NUMBER} - ${RELEASE_NAME}`. No need to include the pipeline name there, especially as it is added by Zenodo later.
4. The release _description_ you enter on GitHub should be the same from what you have in the Changelog, e.g.:

```text
## [[${RELEASE_NUMBER}](https://github.com/sanger-tol/${PIPELINE_NAME}/releases/tag/${RELEASE_NUMBER})] - ${RELEASE_NAME} - [${RELEASE_DATE}]
*Summary of the release*
### Enhancements & fixes
- *List of what's changed. Indicate whether they're bug fixes, additions, or breaking changes*
### Parameters
| Old parameter | New parameter |
| ------------- | ------------- |
| | --added |
| --removed | |
| --old | --new |
> **NB:** Parameter has been **updated** if both old and new parameter information is present. </br> **NB:** Parameter has been **added** if just the new parameter information is present. </br> **NB:** Parameter has been **removed** if new parameter information isn't present.
### Software dependencies
Note, since the pipeline is using Nextflow DSL2, each process will be run with its own [Biocontainer](https://biocontainers.pro/#/registry). This means that on occasion it is entirely possible for the pipeline to be using different versions of the same tool. However, the overall software dependency changes compared to the last release have been listed below for reference.
| Dependency | Old version | New version |
| ------------ | ----------- | ----------- |
| name_removed | 2.30.0 | |
| name_added | | 5.4.3 |
| name_changed | 0.8.10 | 0.8.11 |
> **NB:** Dependency has been **updated** if both old and new version information is present. </br> **NB:** Dependency has been **added** if just the new version information is present. </br> **NB:** Dependency has been **removed** if version information isn't present.
```

Alternatively, GitHub can also generate release notes from the list of commits. Just make sure you have this at the top:

```text
## [[${RELEASE_NUMBER}](https://github.com/sanger-tol/${PIPELINE_NAME}/releases/tag/${RELEASE_NUMBER})] - ${RELEASE_NAME} - [${RELEASE_DATE}]
*Summary of the release*
```

## Integration with Zenodo

Once you've made a release, a record is automatically created on Zenodo.
Tell [@muffato](https://github.com/muffato) or [@DLBPointon](https://github.com/DLBPointon) who can then do the following:

1. Check the release notes. Sometimes the conversion from Markdown doesn't work well, especially the tables. If this happens, copy-paste the rendered Markdwon from GitHub into the Zenodo editor.
2. Change the record type from "Software" to "Workflow".
3. Check that all authors are properly named (first name and last name identified), have an ORCiD, and have the recognised Sanger affiliation (it is named "Wellcome Sanger Institute (WTSI)", not "Wellcome Sanger Institute", and has the [ROR](https://ror.org/05cy4wa09) logo).
4. Add the pipeline to the [sanger-tol Zenodo community](https://zenodo.org/communities/sanger-tol).
5. Check that the licence is correctly set to MIT.
6. In the "Software" section, link to GitHub URL, enter "Nextflow" as the language, and set the "Development Status" to "Active".

## Integration with WorkflowHub

As part of an EBP and ERGA recommendation, we should deposit our workflows into [WorkflowHub](https://workflowhub.eu/programmes/37) too.
There isn't an automated way of doing that yet, so in the meantime we need to manually upload the releases.

In order to upload a record, you will need to create an account and ask to join one of our two teams (["Genome Assembly"](https://workflowhub.eu/projects/204) and ["Genome Analysis"](https://workflowhub.eu/projects/205)).
Instructions are on their website: <https://about.workflowhub.eu/docs/>
2 changes: 1 addition & 1 deletion markdown/events/2023/meetup_nextflow_in_action-oct-2023.md
Original file line number Diff line number Diff line change
Expand Up @@ -25,7 +25,7 @@ It is our hope that these talks / videos will help us learn from the greater Nex

**Adopting Nextflow in Sanger Tree of Life**

Tree of Life is the latest scientific programme of the Wellcome Sanger Institute, aiming at producing reference genome assemblies for tens of thousands of species. We decided early on that Nextflow would be the workflow manager of choice - what an adventure it has been ! In this presentation, I will tell you about our journey, starting from training users, setting up development environments, right up to advertising our complete pipelines and reaching out to users outside of the department, with some insights into deploying and automating the pipelines.
Tree of Life is the latest scientific programme of the Wellcome Sanger Institute, aiming at producing reference genome assemblies for tens of thousands of species. We decided early on that Nextflow would be the workflow manager of choice - what an adventure it has been! In this presentation, I will tell you about our journey, starting from training users, setting up development environments, right up to advertising our complete pipelines and reaching out to users outside of the department, with some insights into deploying and automating the pipelines.

Recording: [YouTube](https://youtu.be/w4RGam3T8iQ)

Expand Down
2 changes: 1 addition & 1 deletion markdown/resources/genome_after_party.md
Original file line number Diff line number Diff line change
Expand Up @@ -92,7 +92,7 @@ If you have an idea for a new feature – [send us your request](https://github.

### Potential features:

_Only if there is an actual demand ! Use the form below to indicate interest._
_Only if there is an actual demand! Use the form below to indicate interest._

- Import features from the [GDA (Genome Decomposition Analysis)](https://github.com/sanger-tol/gda) pipeline, for instance:
- Low complexity repeats from `Dustmasker`
Expand Down
2 changes: 1 addition & 1 deletion markdown/usage/filesystem.md
Original file line number Diff line number Diff line change
Expand Up @@ -3,4 +3,4 @@ title: Tree of Life directory structure
subtitle: The standard directory structure we use to organise our data
---

> Page in progress !
> Page in progress!

0 comments on commit af051a3

Please sign in to comment.