Repository navigation
Fail the release when the tag is not on its release branch - #4668
Merged
Merged
Conversation
A tag created from the GitHub Releases UI can land on the default branch instead of the selected one, which is how v15.1.1 and v15.1.2 were built from 16.x code (#4620). Before building, verify the tagged commit is on release/<major>.x when that branch exists, otherwise on main. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
Branch lookup errors incorrectly trigger fallback to main, potentially allowing a wrong-branch tag to pass validation.
1 open issue
What changed in this PR
Adds a release-workflow guard to prevent publishing packages from the wrong release branch, addressing the mistagged 15.x releases described in #4620.
Changes:
- Selects
release/<major>.xwhen it exists, otherwisemain. - Checks tag ancestry immediately after checkout and stops the release with an error if validation fails.
| File | Description |
|---|---|
.github/workflows/release.yml |
Adds branch selection and tag ancestry validation before building. |
Review effort: Balanced
git ls-remote --exit-code returns 2 for no matching refs and 128 for a failed lookup. Treating any failure as "no release branch" could let a transient error pass a v15.* tag on main. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.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.
Before building, the release workflow now checks that the tagged commit is on the right branch:
release/<major>.xif that branch exists, otherwisemain. If it isn't, the release fails before anything is built, signed or pushed to NuGet.Why
In #4620,
v15.1.1andv15.1.2were created through the GitHub Releases UI. Entering the tag name before picking the branch creates the tag on the default branch, so both "15.x" packages were built from 16.x code (mainat1af71bfe). The UI makes this mistake easy to repeat, and nothing in the pipeline caught it.How
needsthat job, so a failed check stops the release.v15.*requiresrelease/15.x. If arelease/16.xbranch is ever created,v16.*tags will then require it automatically.shell: bash, which also works on the Windows runner.Verification
I ran the same script locally against existing tags:
v15.1.1release/15.xv15.1.2release/15.xv15.1.3release/15.xv16.2.0mainv16.0.0-beta-1mainWorkflow YAML parses, and job dependencies are unchanged.
Companion PR for
release/15.x: #4669🤖 Generated with Claude Code