Implement release-request YAML release model#462
Merged
JasonVranek merged 2 commits intoCommit-Boost:mainfrom Apr 28, 2026
Merged
Implement release-request YAML release model#462JasonVranek merged 2 commits intoCommit-Boost:mainfrom
JasonVranek merged 2 commits intoCommit-Boost:mainfrom
Conversation
ltitanb
previously approved these changes
Apr 27, 2026
ltitanb
approved these changes
Apr 27, 2026
ManuelBilbao
approved these changes
Apr 28, 2026
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.
Summary
This PR refactors the release process so we can safely cut releases from a hotfix branch without having to revert main back to the last release, apply the fix, release, and then replay unrelated work.
The new model keeps the release request PR on main, but allows the referenced release commit to live off-main. The release workflow still runs from the latest workflow definition on main.
Motivation
With the old release process it's a painful sequence if we hit a production problem where a hotfix needs to ship, but main already contained additional good changes that were not release-ready:
That is fragile, high-friction, and easy to get wrong.
This PR changes the process so the release request is still reviewed and merged on main, but the requested release commit can point at a dedicated hotfix branch tip instead.
Assumptions about main branch protection
This design intentionally relies on the existing branch protection and repo policy on the main repository:
Given those guarantees, the release automation does not need to duplicate main's branch-protection checks. The release request PR is the approval point. The release gate is the last authoritative check before tag creation.
New release flow
A PR on main adds .releases/vX.Y.Z.yml
validate-release-request.yml
release-gate.yml
release.yml
Security and trust model
The tag is now the trust anchor.
We intentionally do not trust a free-form tag and commit pair passed into the release workflow. Instead:
This keeps the latest workflow logic on main while preventing dispatch-time injection of an arbitrary tag and commit pair.
What was simplified
This PR removes release-time checks that duplicate guarantees already enforced by main branch protection, or that created unnecessary operational friction:
This PR also keeps the release request model intentionally simple:
Operational notes
validate-release-request.yml remains intentionally separate from release-gate.yml
it is not the security boundary
it is there to provide fast feedback before merge and reduce merge-then-fail churn
release assets are published per binary:
release asset verification now uses the release workflow identity on refs/heads/main, since the workflow runs from main even when building an off-main tagged commit
Additional cleanup
This PR also includes:
###Testing
Covered failure and edge-path testing includes:
Closes #457