Skip to content

ci: pin release tag_name's target_commitish to the triggering commit - #148

Merged
so5 merged 1 commit into
RIKEN-RCCS:mainfrom
so5:ci/release-target-commitish
Sep 23, 2026
Merged

so5 merged 1 commit into
RIKEN-RCCS:mainfrom
so5:ci/release-target-commitish

Conversation

@so5

@so5 so5 commented Sep 22, 2026

Copy link
Copy Markdown
Collaborator

Summary

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.

Impact found

This silently mis-targeted every maintenance/beta release's git tag at main instead of its own branch. Caught after backporting the new release-labeling scheme (#145) to maintenance2023/maintenance2026 (#146, #147) and noticing both fresh releases' tags pointed at main'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

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
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
so5 merged commit 2546d4e into RIKEN-RCCS:main Sep 23, 2026
@so5
so5 deleted the ci/release-target-commitish branch September 23, 2026 04:38
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant