Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add workflow for automatically generating release #2585

Merged
merged 3 commits into from
Jan 31, 2024
Merged

Conversation

inahga
Copy link
Contributor

@inahga inahga commented Jan 30, 2024

Automates the Janus release process.

This workflow, when triggered by workflow_dispatch, will push a version bump commit to each active branch, then create a release on that new commit. That release will then trigger our other workflows, like publishing SQL schema and to crates.io.

There are a few tradeoffs to this approach:

This bypasses status checks. An operator should check the status of the main branch before using this workflow. I omitted an automated check for the latest status check because I don't want to end up in a situation where we have to make arbitrary commits to get the latest status check passing. I generally think that with per-PR status checks, it's very unlikely to release code that is flat out broken--likely blocking status checks would involve new clippy lints when stable is updated, or rustsec violations.

This workflow elegantly but also inelegantly handles prerelease branches. cargo-edit bumps version 0.7.0-prerelease-1 to 0.7.0. This is great for when we're ready to release it for real, but not so great when we need incremental prerelease versions. I don't think there's a tidy solution to this, so we'll just have to handle incremental prerelease versions manually.

There is no facility for supplying extra release notes. I figure we can just edit the created release if we need to add more detail to a set of release notes.

Even with these tradeoffs, this workflow should make releasing Janus a 1-click process (modulo prerelease branches).

Deploying

I will need @branlwyd's help with creating the DIVVIUP_GITHUB_AUTOMATION_RELEASE_PAT secret. We will want to make this an organization secret, so we can roll out this approach to multiple repositories. It will need repo scopes, and it must have an expiration date (otherwise repo cloning won't work).

We will also need to assign divviup-github-automation to the bypass list in the branch protection rules. This is denoted Allow specified actors to bypass required pull requests. I will do this if this PR is approved.

@inahga inahga requested a review from a team as a code owner January 30, 2024 00:08
@inahga
Copy link
Contributor Author

inahga commented Jan 30, 2024

This workflow can be demo'd in https://github.com/divviup/inahga-test.

@inahga
Copy link
Contributor Author

inahga commented Jan 30, 2024

Closes #293

@inahga inahga linked an issue Jan 30, 2024 that may be closed by this pull request
Copy link
Collaborator

@divergentdave divergentdave left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this looks good, it'll take care of some purely mechanical steps

@branlwyd
Copy link
Contributor

I generated a PAT & set the permissions appropriately (I think) -- all non-pictured perms are not checked:

image

This PAT is available via the DIVVIUP_GITHUB_AUTOMATION_RELEASE_PAT org secret.

be marked as the latest release.
required: false
type: string
default: '["release/0.6","release/0.5"]'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess releases for main are currently manual, since it's prerelease?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep. When we're ready to promote it to a production-ready release, we can just run the workflow normally, but in the mean time we'll have to do it manually.

The main blocker is that cargo-edit doesn't really support incrementing prerelease versions. (FWIW I'm not sure if the available alternatives do, like release-plz.)

.github/workflows/make-release.yml Outdated Show resolved Hide resolved
@inahga inahga enabled auto-merge (squash) January 31, 2024 19:16
@inahga inahga merged commit 1d69fbf into main Jan 31, 2024
8 checks passed
@inahga inahga deleted the inahga/make-release branch January 31, 2024 19:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Harden Rust crate releasing against human errors
3 participants