From b0c9a57f1dd63f8436151600970aba4150bd5f57 Mon Sep 17 00:00:00 2001 From: oskaresparza Date: Fri, 14 Aug 2026 13:28:37 +0200 Subject: [PATCH] Fix release tags pointing at the wrong commit MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit softprops/action-gh-release defaults target_commitish to the repo's default branch when unset, not to the branch that triggered the run — so the version-bump and README-sync commits pushed by earlier steps in this same job were silently excluded from the tagged release. Both v0.1.9 and v0.1.9-staging ended up pointing at the same stale commit instead of their respective branch's actual tip. Set target_commitish to github.ref_name so the release tag always lands on this branch's current tip, matching the floating main/staging alias tag. Co-Authored-By: Claude Sonnet 5 --- .github/workflows/release.yml | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml index a75f42e..d0e4135 100644 --- a/.github/workflows/release.yml +++ b/.github/workflows/release.yml @@ -113,11 +113,18 @@ jobs: fi done + # target_commitish is required here: without it, the GitHub API creates + # a brand-new tag from the *repository's default branch* tip, not from + # github.sha (the commit that triggered this run) and not from the + # version-bump/README commits the earlier steps just pushed to this + # branch. Pointing it at github.ref_name makes the release tag land on + # this branch's actual current tip. - name: Create GitHub release uses: softprops/action-gh-release@v3 with: tag_name: v${{ steps.version.outputs.version }}${{ github.ref_name == 'staging' && '-staging' || '' }} name: v${{ steps.version.outputs.version }} (${{ github.ref_name }}) + target_commitish: ${{ github.ref_name }} files: dist/* generate_release_notes: true prerelease: ${{ github.ref_name == 'staging' }}