fix(release-tag): drop floating major tag to satisfy tag-protection ruleset#182
Conversation
…uleset The org-level `ByronWilliamsCPA-tag-protection-semver` ruleset (applied to `refs/tags/v*`) enforces four rules: `deletion`, `non_fast_forward`, `update`, and `tag_name_pattern`. Its bypass list only contains the `RepositoryRole` admin (id=5), so the `github-actions[bot]` identity used by this workflow cannot bypass. The previous design created both an immutable point tag (vX.Y.Z) and a floating major tag (vX) that was force-moved on every release. The floating-tag force-push has been rejected on every push to main since the ruleset was tightened on 2026-05-16, failing the `Release Tag` required check. This change aligns the workflow with the strategy already proven in ByronWilliamsCPA/.claude, which only ever creates immutable point tags and is unaffected by the ruleset. The change: - Removes the `FLOATING` variable, the `git tag -f`, and the `git push origin "$FLOATING" --force` lines. - Updates the header comment to reflect immutable-tag semantics and cite the ruleset. Consumers already pin to full 40-char SHAs per CI-005, so removing the floating `v1` ref has no practical downstream impact. Closes the Release Tag failure on https://github.com/ByronWilliamsCPA/.github/actions/runs/26477814926 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Warning Review limit reached
More reviews will be available in 53 minutes and 39 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✨ 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 |
There was a problem hiding this comment.
Pull request overview
This PR updates the release tagging workflow to stop publishing or force-updating a floating major tag, aligning tag creation with the org-level tag protection ruleset.
Changes:
- Updates workflow comments to document immutable point-tag-only behavior.
- Removes floating major tag creation, logging, and force-push.
- Keeps the annotated
vX.Y.Ztag creation and push path.
| @@ -63,17 +65,12 @@ jobs: | |||
| fi | |||
|
|
|||
| NEW_TAG="v${MAJOR}.${MINOR}.${PATCH}" | |||
|



Summary
vXmajor-tag force-push from.github/workflows/release-tag.yml.vX.Y.Ztag on each push tomain.Why this failed on
mainThe org-level ruleset
ByronWilliamsCPA-tag-protection-semverapplies torefs/tags/v*and enforces:deletion(no tag deletion)non_fast_forward(no force-pushes)update(no tag updates)tag_name_pattern(semver shape)Only the
RepositoryRole adminis in the bypass list. Thegithub-actions[bot]identity used by this workflow is not, so the previousgit push origin v1 --forcewas rejected withGH013: Repository rule violations found for refs/tags/v1.Failing run: https://github.com/ByronWilliamsCPA/.github/actions/runs/26477814926
Why removing the floating tag is the right fix
ByronWilliamsCPA/.claude: that repo only ever publishes immutable point tags (v0.13.0,v0.12.2, ...) and is unaffected by the ruleset.github-actionsto the ruleset's bypass list, but that would open the bypass for every repo in the org, weakening the protection for one workflow's idiosyncratic design.CI-005mandates that consumers pin to full 40-char SHAs. The floatingv1ref was, per the original header comment, "human-readable documentation only." Existing immutablev1.x.ytags remain available for callers that prefer named refs.What changes
FLOATING="v${MAJOR}"echo "Floating tag: $FLOATING"git tag -f "$FLOATING" -m "..."git push origin "$FLOATING" --forcegit tag -a "$NEW_TAG"+git push origin "$NEW_TAG"permissions: contents: writejob-levelTest plan
maincuts a newvX.Y.Ztag and theRelease Tagrequired check goes greenStale
v1tagThe existing floating
v1tag (currently at SHA686b656) is left in place; the ruleset prevents deletion anyway, and consumers that resolved it before this change are unaffected. It will simply not advance further. If desired, an org admin can delete it manually (admin bypass) in a follow-up.Generated with Claude Code