Re-point beta-fw tag on every beta publish#106
Conversation
The rolling beta-fw release tag stays on the commit that was default-branch HEAD when the release was first created. gh release create without --target tags default-branch HEAD, and gh release upload never moves the tag, so the published assets track every beta build while the release source commit does not. Add a step to build-beta.yml that PATCHes the beta-fw tag ref to the built commit after each upload, so the tag always matches the assets. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
|
Caution Review failedFailed to post review comments. We encountered an issue with GitHub. Use ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
⏰ Context from checks skipped due to timeout. (9)
WalkthroughThe beta release workflow now force-updates the rolling ChangesBeta release publishing
Estimated code review effort: 2 (Simple) | ~5 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
Version: unchanged (workflow only)
What does this implement/fix?
The rolling
beta-fwrelease tag was stuck on the commit that was default-branch HEAD when the release was first created (gh release createwithout--targettags default-branch HEAD, andgh release uploadnever moves the tag). The published assets tracked every beta build while the release's source commit did not, so the release page and its source archives pointed at the wrong tree.Adds a step to
build-beta.ymlthat PATCHes thebeta-fwtag ref to the built commit after each upload, so the tag always matches the assets.Types of changes
Checklist / Checklijst:
If user-visible functionality or configuration variables are added/modified:
🤖 Generated with Claude Code
Summary by CodeRabbit