ci: promote final release when the rc fleet gate is green#219
Merged
Conversation
Add a maintainer-CI workflow that publishes the final vX.Y.Z release when Fleet E2E (live GitHub) concludes success for an rc tag. It resolves the rc the same way fleet-e2e does, strips -rc.N, skips when the release or tag already exists, anchors the final tag to the rc's validated commit, drives GoReleaser via an explicit release.yaml dispatch, optionally GPG-signs the tag when a release key secret is set, and verifies the published release is latest, non-prerelease, and carries the expected 5 assets. Signed-off-by: Joshua Temple <joshua.temple@stablekernel.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Problem
When Fleet E2E (live GitHub) validates an rc tag
vX.Y.Z-rc.Nacross the example fleet, promoting that rc to the finalvX.Y.Zrelease is a manual step. The validated binary and the published binary should be the same artifact, and promotion should never happen off a red fleet or double-publish an already-released version.Fix
Add
.github/workflows/auto-promote.yaml, a maintainer-CI workflow:workflow_runof "Fleet E2E (live GitHub)" on completion; proceeds only whenconclusion == 'success'and the run was for an rc tag of shapevX.Y.Z-rc.N. The rc is resolved the same way fleet-e2e's resolve job does (head_branch, with ahead_sha-> tag fallback).-rc.Nto computevX.Y.Z.vX.Y.Zrelease or tag already exists.GITHUB_TOKEN(which does not re-trigger workflows), then explicitly dispatchesrelease.yaml --ref vX.Y.Zso GoReleaser builds that tag. The explicit dispatch is the deterministic path; the event-based Release trigger has been unreliable.CASCADE_RELEASE_GPG_KEYsecret is configured; otherwise creates an annotated, unsigned tag and logs that clearly. Signing never blocks promotion.vX.Y.Zrelease isdraft=false,prerelease=false, has 5 assets, and is the repo's latest release.Least privilege: top-level
contents: read; the promote job addscontents: write(tag/release) andactions: write(dispatch). The fleet PAT is used where a trigger-capable token is needed.This is maintainer CI only - no generator or CLI change, and it does not collide with the generator-owned
promote.yaml.Verification
actionlint .github/workflows/auto-promote.yaml: clean.