From e19a48b694afbeb0051fe42649ba602ab0aaec18 Mon Sep 17 00:00:00 2001 From: Naoyuki Sogo Date: Wed, 23 Sep 2026 01:11:39 +0900 Subject: [PATCH] ci: pin release tag_name's target_commitish to the triggering commit 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 Claude-Session: https://claude.ai/code/session_01C3jKNM1qubomM8UTRdkEWu --- .github/workflows/build_and_deploy.yml | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/.github/workflows/build_and_deploy.yml b/.github/workflows/build_and_deploy.yml index 23ff3e0b..d0838b42 100644 --- a/.github/workflows/build_and_deploy.yml +++ b/.github/workflows/build_and_deploy.yml @@ -77,6 +77,11 @@ jobs: wheel_docker.tar.gz source.tar.gz tag_name: ${{ env.VERSION_NUMBER }} + # without this, the GitHub API creates a brand-new tag against the + # repository's default branch (main) regardless of which branch this + # workflow actually ran on - a maintenance/beta build's tag would + # silently point at main instead of its own branch. + target_commitish: ${{ github.sha }} name: "${{ env.TITLE_PREFIX }} ${{ env.VERSION_NUMBER }}" body: "release for ${{ github.ref_name }} @ ${{ github.sha }} (${{ env.VERSION_NUMBER }})" # only the main line ever takes the "Latest" badge and the