chore: automate releases with Release-plz #545
Conversation
Releasing the console crates has been a bit of a hassle. It requires manual work run locally and as such, we have gone long periods without releases, despite having changes which would be worth releasing. [Release-plz] provides release automation based on GitHub actions. It will create, and then update a PR for the next release. Release-plz depends on [conventional commits] (which the `console` project is already following) to determine the next version number for each crate and then uses [cargo-semver-checks] to check that the version bump is correct. For the changelogs, [git-cliff] is used. Since we already started using in #416, so we can reuse our existing `cliff.toml` config file. A small change has been made to remove the footer, as it was getting included multiple times in a single changelog file due to the delta updates. **Caution**: In order to use Release-plz, a crates.io token first needs to be added to the GitHub project. This means that anyone with PR merge rights will be able to run a release by merging the Release PR. Additionally, GitHub actions need to be given permission to create PRs. The previous scripts used to release have been removed. [Release-plz]: https://release-plz.ieni.dev/ [conventional commits]: https://www.conventionalcommits.org/en/v1.0.0/ [cargo-semver-checks]: https://github.com/obi1kenobi/cargo-semver-checks [git-cliff]: https://git-cliff.org/
|
@hawkw What do you think about this workflow for releases? As mentioned, we will need to add a crates.io token to the action secrets on GitHub, but it would then allow releases entirely from here, no command line shenanigans needed (mostly). |
|
This is the exact workflow (aside from the multiple package config) that I use for a bunch of tui related crates . It's fairly robust and works great. Being able to publish a release just by hitting merge on the release PR and trusting that everything is just handled correctly is an excellent workflow. |
There was a problem hiding this comment.
This looks great, thanks for working on this!
It might be nice to add some documentation to CONTRIBUTING.md (or something) explaining the new release workflow and how to trigger a release, but it's fine to add that in a separate PR.
Do we need to export a cargo registry token secret in the repo settings for the release-plz action to use? I can go do that.
Releasing the console crates has been a bit of a hassle. It requires
manual work run locally and as such, we have gone long periods without
releases, despite having changes which would be worth releasing.
Release-plz provides release automation based on GitHub actions. It
will create, and then update a PR for the next release.
Release-plz depends on conventional commits (which the
consoleproject is already following) to determine the next version number for
each crate and then uses cargo-semver-checks to check that the version
bump is correct.
For the changelogs, git-cliff is used. Since we already started using
in #416, so we can reuse our existing
cliff.tomlconfig file. A smallchange has been made to remove the footer, as it was getting included
multiple times in a single changelog file due to the delta updates.
Caution: In order to use Release-plz, a crates.io token first needs
to be added to the GitHub project. This means that anyone with PR merge
rights will be able to run a release by merging the Release PR.
Additionally, GitHub actions need to be given permission to create PRs.
The previous scripts used to release have been removed.
Review Notes (DO NOT INCLUDE IN COMMIT MESSAGE)
To test the functionality of Release-plz, I copied
consoleinto a separateproject hds_console and played around with it there first.
The series of test PRs can be seen at: https://github.com/hds/hds_console/pulls?q=is%3Apr+is%3Aclosed
This released a series of test crates. The version history for each is:
The first release of each of the test crates was performed with the
existing release script. The subsequent releases were performed
by Release-Plz.