Allow ordinary pushes to a PR branch while its auto-merge is armed - #2028
Conversation
Auto-merge state itself stays user-owned and automation still never disables/re-enables it. But an ordinary fast-forward commit/push while auto-merge is armed is safe -- GitHub re-validates required checks against the new head before it merges, so an additive push cannot slip an unvalidated commit past it. Narrow guard-push.mjs's auto-merge guard from a hard block on any push to a hard block only on a force-push (history rewrite) while armed, which is where the real risk (discarding a commit GitHub already validated/is mid-evaluating) actually lives. Update AGENTS.md and the run-pr/handoff/pr-babysit policy docs to match.
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
This pull request has been ignored for the connected project Preview Branches by Supabase. |
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in:39 minutes Limit details: You’ve used all 1 included review currently available under your plan. You completed 95 included PR reviews in the past 7 days; at that activity level, included reviews refill at 1 review per hour. Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab. 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. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (7)
Included review availability: 0 reviews are currently available. Based on recent review activity, included reviews refill at 1 per hour. 📝 WalkthroughWalkthroughThe push guard now permits fast-forward pushes with armed auto-merge, blocks armed force-pushes, and preserves auto-merge state. Tests and automation guidance reflect the updated policy. ChangesAuto-merge push safety
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk:⚪ Minimal · up to This change narrows the push guard to continue blocking force-pushes while allowing ordinary updates to auto-merge branches; no actionable merge-blocking risk remains after normal checks and review. Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
Comment |
|
| GitGuardian id | GitGuardian status | Secret | Commit | Filename | |
|---|---|---|---|---|---|
| 36221231 | Triggered | Generic High Entropy Secret | c5f3736 | tests/rag-adversarial-fixtures.test.ts | View secret |
🛠 Guidelines to remediate hardcoded secrets
- Understand the implications of revoking this secret by investigating where it is used in your code.
- Replace and store your secret safely. Learn here the best practices.
- Revoke and rotate this secret.
- If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.
To avoid such incidents in the future consider
- following these best practices for managing and storing secrets including API keys and other credentials
- install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.
🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.
Uh oh!
There was an error while loading. Please reload this page.
Summary
scripts/guard-push.mjs's auto-merge guard from "block any push to a PR branch whose auto-merge is armed" to "block only a force-push (history rewrite) to that branch." An ordinary fast-forward commit/push is now allowed through (with a warning note): GitHub re-validates required checks against the new head before it will merge, so an additive push cannot make it merge something that was never validated. A force-push while armed is the genuinely unsafe case — it can discard the commit GitHub already validated or is mid-evaluating — so that still hard-blocks with no override, matching the guard's existing no-override design for this check.isForcePushRange/forcePushedBranchNameshelpers toscripts/guard-push.mjs(ancestry-based force-push detection, reusing the same fast-forward logic the drift/static guards already rely on) and updateautoMergeVerdict/autoMergeGuardto take a force-push flag into account.AGENTS.md(Run PR shortcut guardrails, PR bundling, and the anti-conflict/CI-speed section),.claude/skills/run-pr/SKILL.md,.claude/skills/handoff/SKILL.md, and.cursor/agents/pr-babysit.mdto match: auto-merge state remains user-owned (automation still never disables/re-enables it), but ordinary pushes, review-thread fixes, andmain-sync pushes are no longer described as "mutation-frozen" while auto-merge is armed — only a force-push or base/target change is.tests/guard-push.test.tswith coverage for the new fast-forward-vs-force-push verdict split and theisForcePushRange/forcePushedBranchNameshelpers (using the existing git-fixture pattern already used for the drift-guard force-push test). The existing "manual auto-merge ownership policy" meta-test (which asserts every listed policy doc still says auto-merge state is user-owned and must not be disabled) still passes unchanged.Verification
npm run verify:pr-local— full run, all stages completed, zero failures:Test Files 635 passed (635),Tests 6775 passed | 4 skipped (6779); summary linefailed: (none),not reached: (none).node scripts/run-vitest.mjs run --reporter=dot tests/guard-push.test.ts(targeted, before the full run) —Test Files 1 passed (1),Tests 33 passed (33).npm run guard:push:self-test—[guard-push] self-test passed.npm run verify:ui— not run; no UI/routing/browser/styling behavior changed (this PR only touches git-push tooling and its docs).npm run verify:release— not run; not a release/handoff-confidence request.Risk and rollout
SKIP_STATIC_GUARD-style env-var overrides are not applicable here since the auto-merge guard deliberately has none) to restore the previous "block any push while armed" behavior..githooks/pre-push→scripts/guard-push.mjs) and agent-facing policy docs; it does not touch GitHub Actions workflows, Supabase, OpenAI, or deployment configuration.Notes
Generated by Claude Code
Summary by CodeRabbit
New Features
Bug Fixes
Documentation