Skip to content

Fix beta release tags pointing at the wrong commit - #6337

Open
VPS-thodax wants to merge 1 commit into
mainfrom
claude/release-tag-main
Open

Fix beta release tags pointing at the wrong commit#6337
VPS-thodax wants to merge 1 commit into
mainfrom
claude/release-tag-main

Conversation

@VPS-thodax

@VPS-thodax VPS-thodax commented Sep 8, 2026

Copy link
Copy Markdown
Contributor

#6319 for main

Problem

Beta releases on next tag the wrong commit: the tag lands on the newest main commit instead of the commit that was released.

v10.0.0-beta.0 points at 0e9bb5fc4 ("Remove leftover .cspellignore (#6158)"), a main commit.

Cause

dotansimha/changesets-action calls the create-release API without target_commitish, so GitHub creates the tag on the repository's default branch.

Fix

The release workflows create the vX.Y.Z tag themselves before the action runs. GitHub ignores target_commitish when the tag already exists, so the release attaches to the correct commit. A second step then asserts the tag ended up on the released commit and fails the job otherwise.

release-beta.yml is the one that is actually broken here, since it runs on next. release.yml gets the same steps even though main is the default branch and therefore unaffected today: it is the template the vN.x.x branches are cut from, and it should not start tagging wrongly if the default branch ever changes.

Verification

  • Confirmed working on v8.x.x. The first release after #6319 merged, v8.32.0, is tagged on cf9fc0cf2 — the release commit on v8.x.x, no longer a main commit.

Further information

🤖 Generated with Claude Code

https://claude.ai/code/session_01EgLEUzTiJX7Jn3WQJBWhok


Generated by Claude Code

Beta releases on next tag the wrong commit: the GitHub release ends up on the
newest main commit instead of the commit that was actually released. v10.0.0-beta.0
is tagged on 0e9bb5f, a main commit. The package tags created by
`changeset publish` are correct, which is why only the aggregated vX.Y.Z tag is
affected.

dotansimha/changesets-action calls the create-release API without passing
target_commitish, so GitHub creates the tag on the repository's default branch.
Creating the tag ourselves before the action runs fixes this, because GitHub
ignores target_commitish when the tag already exists. A second step asserts the
result so a broken guard turns into a red job instead of another wrong tag.

release.yml is not affected today because main is the default branch, but it
gets the same steps: it is the template the vN.x.x branches are cut from, and it
should not break silently if the default branch ever changes.

Same change as on v8.x.x, where it is confirmed working: v8.32.0 is tagged on
cf9fc0c, the release commit on v8.x.x.

DEX-2597

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EgLEUzTiJX7Jn3WQJBWhok
@coderabbitai

coderabbitai Bot commented Sep 8, 2026

Copy link
Copy Markdown

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yml

Review profile: CHILL

Plan: Advanced

Run ID: 94bf382e-9177-45aa-b1ab-6f15eeef00b1

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

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.

3 participants