Tag releases with Brussels #2270
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The first phase of the SP and RoT release process is to determine the version number, tag the latest commit with that version number, and push it to kick off the build. To start fully automating the SP release process, this PR replaces this phase with a single GitHub Actions workflow that can be started through the UI:
This uses Brussels, the new SP and RoT release tooling I'm working on, and in particular the changes I introduced in oxidecomputer/brussels#3. Brussels is fetched as a pre-built binary from its GitHub Release to ensure it doesn't delay the release process by trying to compile it.
The
brussels init
command will be executed in its own job as the first build step. It will look at all the existing tags to determine what is the next version number, calculate the tag name, and expose all of that information intoGITHUB_OUTPUT
to let the rest of the workflow know the version to use. It will also write all the metadata it gathered in abrussels-manifest.json
file, so that future Brussels steps can reference that metadata.The tag will not be created and pushed by
brussels init
. Instead, we will let the "create GitHub Release" step at the end of the workflow create the tag on its own, as GitHub will do so when creating a release without an underlying tag.While I was there, I also changed the build process to inject the version number directly during the build, instead of waiting for permslip to add it as part of the signature process.
This is just the first improvement to the SP release process that I'm going to do. The end goal is for SP releases to be fully automated (either by requiring a single button click or by putting the whole release process in a cronjob).
Note that by default the workflow will use the latest release of Brussels. An optional field when starting the workflow run lets you download Brussels from a CI job in the Brussels repository. This mostly exists to help me test changes without publishing endless releases.