Fix release tag commit

[james-toussaint]

Fixes #4699

The github.ref_name happens to be empty, which makes target_commitish empty.
If target_commitish is empty, it defaults to the repository's default branch (here master), hence the release tag, created during Create Release Github API call, is attached to the wrong commit. (See create-a-release).

PR Checklist

• Tests

• Release tag is attached to the latest commit of the branch being built by the release job.

• Test diff compared to current branch parent commit

• Documentation

[changeset-bot]

⚠️ No Changeset found

Latest commit: 6ba2b1b

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[ernestognw]

Interesting. Thanks for looking into this @james-toussaint!
Any idea why the github.ref_name is empty in some contexts?

[coderabbitai]

Walkthrough

The release workflow now explicitly captures the Git commit hash and passes it through to the GitHub release creation script. A new workflow step writes the current commit hash to the environment variable RELEASE_COMMIT. The github-release.js script validates this variable and uses it as the target_commitish for release creation instead of github.ref_name. The script includes error handling to exit if the environment variable is missing.

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title Check	✅ Passed	The title "Fix release tag commit" directly and clearly summarizes the primary change in the pull request. It accurately reflects that the PR addresses the issue where release tags are attached to the wrong commit by improving how the commit reference is specified in the release workflow. The title is concise, specific, and meaningful to someone reviewing the commit history.
Linked Issues Check	✅ Passed	The PR directly addresses the objective stated in linked issue #4699 to fix release tagging. The issue reports that the wrong commit gets tagged as the released commit, and this PR identifies and fixes the root cause: when github.ref_name is empty, target_commitish defaults to the repository's default branch (master). The solution adds explicit commit capture to the workflow and validates the RELEASE_COMMIT environment variable before use, ensuring releases are tagged to the correct commit. The changes directly implement the necessary fix to prevent release tags from being attached to wrong commits.
Out of Scope Changes Check	✅ Passed	All changes in this PR are directly scoped to fixing the release tagging issue described in #4699. The modifications to the release workflow (capturing the commit hash) and the github-release script (validating and using the commit reference) are both necessary and sufficient to address the identified root cause. No unrelated refactoring, feature additions, or changes outside the release process are present in the changeset.
Description Check	✅ Passed	The pull request description is clearly related to the changeset and provides specific, meaningful context about the changes. The author explains that github.ref_name is empty in some contexts, which causes target_commitish to be empty when creating a release, resulting in the release tag being attached to the wrong commit (the repository's default branch instead of the correct commit). The changeset directly implements the solution to this problem: adding a new step to capture and store the commit hash in GITHUB_ENV and modifying the release script to use this RELEASE_COMMIT variable instead of github.ref_name. The description is neither vague nor generic—it describes the specific problem and its consequences in relation to the GitHub Releases API behavior.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[james-toussaint]

Any idea why the github.ref_name is empty [...]?

Here github is an Octokit object featuring .request, .graphql, .. I don't see no .ref_name available.

[Amxx]

Are we able to test it without doing a release ?

Worst case the tag is not correct, and we fix it manually like before ... until we finally find the correct fix. But ideally I'd like to not do this kind of (slow) trial and error.

Alternativally, any code out these uses a similar workflow ? Can we check which value they use ?

[james-toussaint]

Are we able to test it without doing a release ?

Worst case the tag is not correct, and we fix it manually like before ... until we finally find the correct fix. But ideally I'd like to not do this kind of (slow) trial and error.

Alternativally, any code out these uses a similar workflow ? Can we check which value they use ?

@Amxx

Tested with Github Actions in personal fork (links in PR description). (I can give you access to jobs if you need to)

We would need to setup some sort of full staging env (kind of similar to what I did with my personal fork), accessible to everyone internally. Not sure it's worth it here.

Here is a similar example/workflow.

[frangio]

🤯

The docs here were the cause of the confusion: https://docs.github.com/en/actions/reference/workflows-and-actions/contexts#github-context

The "context" is called github in a workflow file, so we wrote github.ref_name in this script even though github refers to another kind of object. I believe context.ref_name would also have fixed the bug (but context.sha should have the same effect).

TypeScript would've caught this!