Repository navigation
ci(release): add release-tag-guard backstop for release-please auto-tag - #1523
Conversation
release-please's group-pull-request-title-pattern fix got the version into the
release PR title, but it STILL aborted ('untagged, merged release PRs
outstanding') and did not tag v2.20.1 on merge — its release-creation step is
unreliable here (squash-merge association + accumulated manual-tag state).
Add a deterministic guard: on a .release-please-manifest.json bump (release PR
merge), ensure v<version> tag + GitHub Release exist; create them via the PAT
(so release: published fires deploy) if release-please did not. Idempotent —
no-op when the tag already exists. ADR updated with the validation outcome.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
There was a problem hiding this comment.
Your free trial has ended. If you'd like to continue receiving code reviews, you can add a payment method here.
📝 WalkthroughWalkthroughA new GitHub Actions workflow ChangesRelease Tag Guard Workflow and Decision Record
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
|
Failed to generate code suggestions for PR |
There was a problem hiding this comment.
2 issues found across 2 files
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
cubic P1: key idempotency on the GitHub Release (gh release view), not just the tag — a partial prior run (tag pushed, release-create failed) would otherwise skip on rerun and leave deploy broken. Now skip only if the Release exists; else create the tag if missing, then the Release. cubic P2: reconcile adr alternatives/consequences/plan/revisit sections to reflect the guard is shipped and primary, not future.
There was a problem hiding this comment.
Your free trial has ended. If you'd like to continue receiving code reviews, you can add a payment method here.
There was a problem hiding this comment.
🧹 Nitpick comments (1)
.github/workflows/release-tag-guard.yml (1)
32-32: 🧹 Nitpick | 🔵 TrivialConsider pinning
actions/checkoutto a commit SHA for supply-chain security.While pinning actions to commit SHAs is a security best practice, the repo does not consistently apply this pattern—most workflows use version tags (
@v6,@v7, etc.) for standard GitHub actions. Only select third-party actions are pinned to SHAs.Note: Credentials must persist here for the
git pushon line 59, sopersist-credentials: falseis correctly not used.🔒 Suggested fix
- - uses: actions/checkout@v4 + - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/release-tag-guard.yml at line 32, The actions/checkout action at line 32 should be pinned to a specific commit SHA instead of using the version tag `@v4` for enhanced supply-chain security. Replace the version tag with the appropriate commit SHA (you can find the current SHA for the v4 release on the GitHub Actions checkout repository). Keep persist-credentials at its default value (true) since the git push operation on line 59 requires valid credentials to work.Source: Linters/SAST tools
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In @.github/workflows/release-tag-guard.yml:
- Line 32: The actions/checkout action at line 32 should be pinned to a specific
commit SHA instead of using the version tag `@v4` for enhanced supply-chain
security. Replace the version tag with the appropriate commit SHA (you can find
the current SHA for the v4 release on the GitHub Actions checkout repository).
Keep persist-credentials at its default value (true) since the git push
operation on line 59 requires valid credentials to work.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 562174d2-d4e2-4e75-a089-cecafe4edef8
📒 Files selected for processing (2)
.github/workflows/release-tag-guard.ymldecisions/2026-06-22-release-please-group-title-pattern.md
📜 Review details
⏰ Context from checks skipped due to timeout. (13)
- GitHub Check: Test — shared
- GitHub Check: Test — bot
- GitHub Check: Test — backend
- GitHub Check: Test — frontend
- GitHub Check: Checks
- GitHub Check: cubic · AI code reviewer
- GitHub Check: danger / danger
- GitHub Check: quality / Lint (lint)
- GitHub Check: quality / Dead code (knip)
- GitHub Check: quality / SAST (CodeQL) (javascript-typescript)
- GitHub Check: Security
- GitHub Check: Build — frontend
- GitHub Check: Build — bot
🧰 Additional context used
🪛 LanguageTool
decisions/2026-06-22-release-please-group-title-pattern.md
[uncategorized] ~39-~39: The official name of this software platform is spelled with a capital “H”.
Context: ...durable fix is the CI auto-tag guard** (.github/workflows/release-tag-guard.yml), ship...
(GITHUB)
[uncategorized] ~44-~44: The official name of this software platform is spelled with a capital “H”.
Context: ...primary durable mechanism** (shipped in .github/workflows/release-tag-guard.yml), beca...
(GITHUB)
🪛 zizmor (1.26.1)
.github/workflows/release-tag-guard.yml
[warning] 32-35: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[error] 32-32: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🔇 Additional comments (5)
decisions/2026-06-22-release-please-group-title-pattern.md (1)
33-75: LGTM! The updated decision document accurately documents the validation outcome, properly promotes the CI guard to primary mechanism, and comprehensively frames the decision and its revisit triggers.Spot-checks confirm alignment with the workflow implementation:
- Line 52's claim that "guard guarantees the
v<version>tag + GitHub Release" matches the workflow's idempotent logic (checks Release existence viagh release view, creates tag+Release if missing).- Line 57's "Release-existence check makes this safe" correctly describes the workflow's idempotency strategy (keyed on Release, not tag).
- Line 74's multi-package limitation accurately identifies the guard's single-
${version}assumption, a real constraint in the current setup.- Line 73's revisit trigger for "neither release-please nor the guard tagging" is a sound regression detector.
The validation outcome section appropriately documents why the title fix alone was insufficient (release-please still aborted post-merge despite correct PR title), justifying the guard's promotion from companion to primary. The alternatives section clearly frames the tradeoff decisions.
.github/workflows/release-tag-guard.yml (4)
1-17: LGTM!
18-22: LGTM!
24-25: LGTM!
37-65: LGTM!
|



Why
The
group-pull-request-title-patternfix (PR #1521) got the version into the release PR title (chore: release 2.20.1✅) — but on merge, release-please still aborted (untagged, merged release PRs outstanding) and did not tag v2.20.1. Withskip-github-release: false+ the PAT, its release-creation step is still unreliable here (squash-merge association + accumulated manual-tag state). v2.20.1 was tagged via the manual workaround one last time.So release-please's auto-tag can't be relied on. This adds a deterministic backstop.
What
.github/workflows/release-tag-guard.yml— on a.release-please-manifest.jsonbump (i.e. a release PR merged to main), ensurev<version>exists:release: publishedfiresdeploy.yml).Idempotent, paths-filtered to fire only on release merges. Pairs with the title fix (kept as a precondition).
Validation
v<version>untagged — exactly the 4× failure mode.ADR:
decisions/2026-06-22-release-please-group-title-pattern.md(updated with the validation outcome). decision-critic recommended shipping this alongside the config fix.Summary by cubic
Add a CI guard that auto-creates the
v<version>tag and GitHub Release after a manifest bump, as a backstop for unreliablerelease-pleaseauto-tagging. It prevents silent deploy skips by ensuring the release is published via the PAT and is idempotent on the GitHub Release..github/workflows/release-tag-guard.ymltriggered on.release-please-manifest.jsonchanges tomain.v<version>exists → no-op; if missing → create the tag (if absent) and the Release usingRELEASE_PLEASE_TOKENsorelease: publishedtriggersdeploy.yml.Written for commit 62cf24d. Summary will update on new commits.
Summary by CodeRabbit