ci: pin release tag_name's target_commitish to the triggering commit - #148
Merged
Merged
Conversation
softprops/action-gh-release's tag_name creates a brand-new git tag when one doesn't already exist. Without an explicit target_commitish, the GitHub API defaults that new tag to the repository's default branch (main) - not the branch the workflow actually ran on. This silently mis-targeted every maintenance/beta release's tag at main instead of its own branch (caught after backporting the release-labeling scheme to maintenance2023/2026 and noticing both fresh releases' tags pointed at main's merge commit instead of the maintenance branch's own commit; fixed in place via the git refs API, no rebuild needed). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01C3jKNM1qubomM8UTRdkEWu
This was referenced Sep 22, 2026
so5
added a commit
that referenced
this pull request
Sep 23, 2026
Same fix as #148 on main, backported here: without an explicit target_commitish, softprops/action-gh-release's tag_name creates a new tag defaulted to the repository's default branch (main), not the branch this workflow actually ran on - silently mis-targeting this branch's release tags at main instead of maintenance2026's own commits. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01C3jKNM1qubomM8UTRdkEWu
so5
added a commit
that referenced
this pull request
Sep 23, 2026
Same fix as #148 on main, backported here: without an explicit target_commitish, softprops/action-gh-release's tag_name creates a new tag defaulted to the repository's default branch (main), not the branch this workflow actually ran on - silently mis-targeting this branch's release tags at main instead of maintenance2023's own commits. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01C3jKNM1qubomM8UTRdkEWu
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
softprops/action-gh-release'stag_namecreates a brand-new git tag when one doesn't already exist. Without an explicittarget_commitish, the GitHub API defaults that new tag to the repository's default branch (main) - not the branch the workflow actually ran on.Impact found
This silently mis-targeted every
maintenance/betarelease's git tag atmaininstead of its own branch. Caught after backporting the new release-labeling scheme (#145) tomaintenance2023/maintenance2026(#146, #147) and noticing both fresh releases' tags pointed atmain's merge commit instead of their own branch's commit. The uploaded release assets themselves were unaffected (built and uploaded from the correctly-checked-out branch within the same job run) - only the tag's target commit was wrong, which matters if anyone browses the tag's source on GitHub.Already fixed in place for the two existing releases via the git refs API (no rebuild needed); this PR prevents it from recurring on every future release across all three lines (main/maintenance/beta).
Change
Add
target_commitish: ${{ github.sha }}to the release step.🤖 Generated with Claude Code
https://claude.ai/code/session_01C3jKNM1qubomM8UTRdkEWu