Use GitHub Actions to perform new releases #595
Assignees
Labels
enhancement
New feature or request
Comments
edmorley
added a commit
that referenced
this issue
Sep 25, 2023
Libcnb.rs uses a two stage release process. Until now both of those stages required a maintainer to perform the steps manually: https://github.com/heroku/libcnb.rs/blob/main/RELEASING.md This new GitHub Actions workflow replaces the manual steps in the first half of the release process, leading up to the creation of the "Prepare release" PR. In the future, the second stage of the release process will be automated too, but that will require sorting out a service account (which will also have to be backed by a GitHub account, since currently crates.io only supports login via GitHub oauth). See also: https://github.com/killercup/cargo-edit#cargo-set-version https://github.com/heroku/languages-github-actions/blob/main/.github/workflows/_buildpacks-release.yml First part of #595. GUS-W-13977983.
edmorley
added a commit
that referenced
this issue
Sep 25, 2023
In #689, a GitHub Actions workflow was added for the first stage of the release process - preparing the release PR. Now, another workflow has been added for the second stage of the release process - publishing to https://crates.io and creating the GitHub Release. This workflow makes use of the `cargo-release` tool, which calculates the crate dependency graph for us, so we don't need to hardcode a crate publish ordering: https://github.com/crate-ci/cargo-release/blob/master/docs/reference.md This tool also skips any already-published crates, so if say a release failed halfway through publishing to crates.io, the job could be retriggered and would successfully resume publishing. The new workflow does however perform a single check to see if the GitHub Release already exists, to prevent accidentally re-running an already completed successfully release (which might move the git tag): https://cli.github.com/manual/gh_release_view Credentials are configured via the `CARGO_REGISTRY_TOKEN` env var, which has been set to the scoped crates.io API token of a service account. That service account has already been added to the `libcnb*` and `libherokbuildpack` crates: https://doc.rust-lang.org/cargo/reference/config.html#credentials https://crates.io/users/heroku-languages-release-bot heroku/languages-team#146 The awk-based changelog extraction technique was inspired by: https://stackoverflow.com/questions/38972736/how-to-print-lines-between-two-patterns-inclusive-or-exclusive-in-sed-awk-or Closes #595. GUS-W-14177169.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently new libcnb.rs releases are performed via a sequence of locally run manual steps:
https://github.com/heroku/libcnb.rs/blob/main/RELEASING.md
We should (a) automate these, (b) perform them on GitHub Actions, in order to:
cargo-semver-checksto validate version bumps for new releases #596)We might be able to make use of one or more of these tools:
https://github.com/killercup/cargo-edit#cargo-set-version
https://github.com/crate-ci/cargo-release
https://github.com/Byron/cargo-smart-release
The text was updated successfully, but these errors were encountered: