ci: Gate push-triggered publish and cancel on release-stamping commits#1901
Conversation
Normal feature-PR pushes to main/v3-beta were being evaluated as release retries because the resolver only checked release/asset state. Add a push-event gate that requires HEAD to actually stamp the project runner version (diff-based check reusing release_commit_updates_cli_version) before allowing publish/release; workflow_dispatch keeps the old state-based evaluation for retries. Also drop the now-unused CLI_RELEASE_INPUT_PATHS/ latest_cli_asset_release_tag/cli_release_inputs_changed dead code and rewrite the test suite for the new gate behavior.
Mirror the native CLI resolver's push gate: add release_commit_updates_dispatcher_version to check whether HEAD's diff stamps the dispatcher contract or CHANGELOG, and require it on push events before allowing publish/release. workflow_dispatch keeps the state-based evaluation for retrying an incomplete release. Update the test suite to cover stamped/unstamped push and workflow_dispatch cases.
BEFORE_SHA (github.event.before) was never referenced by scripts/resolve-native-cli-release-target.sh; the new push gate uses the checked-out HEAD commit instead.
version-series-realignment.md described dispatcher-publish as reacting to every push regardless of commit content; that's no longer true now that push only evaluates when HEAD stamps the resolved version. release-recovery-runbook.md's operational notes still implied later push builds could retry recreating a deleted broken release. Update both to describe the new gate and the workflow_dispatch-only retry path.
|
Warning Review limit reached
Next review available in: 40 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughPush-based dispatcher and native CLI release resolution now require the HEAD commit to stamp the resolved version. Native CLI decisions use current release and asset state, while tests and recovery documentation cover stamped pushes, skipped pushes, reruns, and manual dispatch. ChangesRelease gating and recovery
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant Push or dispatcher
participant Release workflow
participant Release resolver
participant Git
participant GitHub Releases
Push or dispatcher->>Release workflow: Start publish evaluation
Release workflow->>Release resolver: Pass event and target version
Release resolver->>Git: Inspect HEAD version stamp
Git-->>Release resolver: Return contract or changelog diff
Release resolver->>GitHub Releases: Query release and assets
GitHub Releases-->>Release resolver: Return release state
Release resolver-->>Release workflow: Set publish and release decisions
Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 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 |
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
scripts/resolve-dispatcher-release-target.sh (1)
184-196: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winPush-gate wiring looks correct given the intended stamping semantics.
BUILD_SHAcapture and thepush+unstamped short-circuit correctly force both outputs tofalseand point atworkflow_dispatch, matching the PR's stated behavior and the downstream workflow'ssteps.release.outputs.publish/releasegating. See the related comment on lines 126-143 regarding the merge-commit diff caveat that this branch depends on.🤖 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 `@scripts/resolve-dispatcher-release-target.sh` around lines 184 - 196, Preserve the existing push-gate wiring in the dispatcher release evaluation: capture BUILD_SHA, and when CAN_EVALUATE_DISPATCHER_RELEASE is true but the push HEAD does not satisfy release_commit_updates_dispatcher_version for VERSION, set both SHOULD_PUBLISH and SHOULD_RELEASE to false and direct retries to workflow_dispatch. Do not alter the established prerelease or downstream output-gating behavior.
🤖 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.
Inline comments:
In `@scripts/test-resolve-native-cli-release-target.sh`:
- Around line 260-261: Update the INPUT_RELEASE_TAG assignment in the test
invocation to use an explicit empty-string literal rather than a space after the
equals sign, while preserving the existing empty release-tag behavior.
---
Outside diff comments:
In `@scripts/resolve-dispatcher-release-target.sh`:
- Around line 184-196: Preserve the existing push-gate wiring in the dispatcher
release evaluation: capture BUILD_SHA, and when CAN_EVALUATE_DISPATCHER_RELEASE
is true but the push HEAD does not satisfy
release_commit_updates_dispatcher_version for VERSION, set both SHOULD_PUBLISH
and SHOULD_RELEASE to false and direct retries to workflow_dispatch. Do not
alter the established prerelease or downstream output-gating behavior.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 919a9583-0278-4040-96c0-f170b61fe403
📒 Files selected for processing (7)
.github/workflows/native-cli-publish.ymldocs/release-recovery-runbook.mddocs/version-series-realignment.mdscripts/resolve-dispatcher-release-target.shscripts/resolve-native-cli-release-target.shscripts/test-resolve-dispatcher-release-target.shscripts/test-resolve-native-cli-release-target.sh
💤 Files with no reviewable changes (1)
- .github/workflows/native-cli-publish.yml
The single retry paragraph conflated two different failure modes: an unstamped/cancelled dispatcher-publish push run, and a failed release-please workflow run. Its trailing "once the release exists with all assets" precondition only applied to the release-please retry case, but read as applying to the unstamped-push case too, which can never satisfy it. Split into two separate paragraphs, one per failure mode.
CodeRabbit flagged INPUT_RELEASE_TAG= \ (shellcheck SC1007: space after = looks like a typo for ==). Use an explicit empty-string literal instead.
|
@coderabbitai Thanks for the confirmation on the dispatcher push-gate wiring (lines 184-196). Re: the merge-commit diff caveat you flagged (a true merge commit would make Fixed the shellcheck SC1007 nit in cbe9fac. |
|
Tip For best results, initiate chat on the files or code changes.
Noted the SC1007 fix in ✏️ Learnings added
If you found this review helpful, would you consider giving us a shout-out on X? Thank you for using CodeRabbit! |
Summary
native-cli-publishanddispatcher-publishboth fire on every push tomain/v3-beta, and their resolver scripts decide
publish/releasepurelyfrom release/asset state. That means an ordinary feature-PR merge push gets
evaluated the same way as a release retry, and — because their
Cancel superseded approval-waiting runsstep runs wheneverpublish == 'true' || release == 'true'— an ordinary push run can cancel alegitimate release run that is still waiting on the
cli-releaseenvironmentapproval.
This PR adds a push-event gate to both resolvers: on
push, publish/releaseare only allowed when HEAD's diff actually stamps the resolved version (the
release-please manifest/contract entry, or the component's
CHANGELOG.mdheading) via a new/reused
release_commit_updates_*_versionpredicate.Everything else on push resolves to
publish=false/release=false, so thecancel step no longer fires for it either.
workflow_dispatchbypasses thegate and keeps the previous state-based evaluation, so retrying an
incomplete release is still possible — just not automatic on every push.
scripts/resolve-native-cli-release-target.sh: collapse the old two-blockpublish/release evaluation into one gate, reusing
release_commit_updates_cli_version; remove now-deadCLI_RELEASE_INPUT_PATHS/latest_cli_asset_release_tag/cli_release_inputs_changed.scripts/resolve-dispatcher-release-target.sh: addrelease_commit_updates_dispatcher_versionand the same push gate.BEFORE_SHAenv fromnative-cli-publish.yml.docs/version-series-realignment.mdanddocs/release-recovery-runbook.mdto describe the new gate and theworkflow_dispatch-only retry path.No
cli/release-automationor shared-release-input files changed, soscripts/stamp-release-inputs.sh/scripts/check-go-cli.share notrequired for this PR.
Test plan
sh -n scripts/resolve-native-cli-release-target.shsh -n scripts/resolve-dispatcher-release-target.shscripts/test-resolve-native-cli-release-target.shscripts/test-resolve-dispatcher-release-target.shscripts/test-native-cli-publish-workflow.shscripts/test-dispatcher-publish-workflow.shactual current HEAD (a non-stamping commit) with
EVENT_NAME=push EVENT_REF_NAME=v3-beta— both reportpublish=false/release=falsewith the expected skip message pointing at
workflow_dispatch.