ci: debounce auto-rebase by 30 minutes#29
Conversation
A push to dev currently fires the rebase loop immediately, and every rebased PR head triggers that PR's build pipeline. When a few PRs land in quick succession, the multiplier kicks in: 3 merges × 5 open PRs = 15 PR-build firings inside a few minutes. The per-PR `cancel-in-progress` on `pr-checks.yaml` cancels back-to-back builds on the same PR head, but doesn't help across PRs. Add a 30-minute debounce: - Flip the concurrency policy to `cancel-in-progress: true` so a new push during the sleep kills the still-sleeping run. - Add a leading `sleep 1800` step gated on `github.event_name == 'push'`. Manual `workflow_dispatch` invocations skip the sleep so a maintainer who needs an urgent rebase isn't blocked. End state: one rebase pass per quiet 30-minute window regardless of how many merges land in it. CI load becomes proportional to landings/half-hour rather than landings × open-PR-count.
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, 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 have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml 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 Auto-rebase open PRs GitHub Actions workflow to reduce CI churn caused by bursts of merges into dev, by debouncing the auto-rebase pass and adjusting concurrency so only the latest push “wins” during the debounce window.
Changes:
- Add a 30-minute debounce (
sleep 1800) before rebasing when the workflow is triggered by apushtodev. - Change workflow concurrency to
cancel-in-progress: trueso newer pushes replace older in-flight runs. - Ensure
workflow_dispatchruns skip the debounce to allow urgent/manual rebases immediately.
Comments suppressed due to low confidence (1)
.github/workflows/auto-rebase-prs.yaml:52
- This
sleep 1800holds a GitHub-hosted runner for 30 minutes doing no work. Ifdevreceives frequent pushes, that can consume a lot of runner-minutes and can also starve the rebase indefinitely (each new push cancels and restarts the timer). If runner utilization is a concern, consider an approach that doesn’t occupy a runner while waiting (e.g., a scheduled workflow that runs every 30 minutes and rebases only ifdevadvanced since the last run), or add a bounded max-wait/fallback so rebases still happen under sustained activity.
- name: Debounce dev-push storms
# Only debounce when fired by a push to dev. Manual dispatches run
# immediately. If another push lands during this sleep, the
# concurrency policy above cancels this run before it does any
# work, and the new push gets its own debounce. Coalesces a
# burst of PR merges into a single rebase pass per PR, keeping
# the PR-build CI load proportional to landings/half-hour rather
# than landings × open-PR-count.
if: github.event_name == 'push'
run: sleep 1800
Copilot finding on PR #29: `cancel-in-progress: true` on the single-job workflow would cancel not just during the debounce sleep but also during peter-evans/rebase's force-push phase. That could leave PR heads half-rebased — some pushed, some not, or worse, a push interrupted mid-operation. Split the workflow into two jobs with distinct concurrency: - `debounce`: sleeps 30 min on push events. Cancellable (`cancel-in-progress: true`) so a fresh push kills the still-sleeping run and starts a new timer. - `rebase`: depends on `debounce`, runs peter-evans/rebase. NOT cancellable (`cancel-in-progress: false`) — once force-pushes begin, a subsequent dev push queues behind it rather than interrupting mid-flight. End state: one rebase pass per quiet 30-min window, no half-done rebases.
Summary
auto-rebase-prs.yamlso a burst of PR merges intodevcoalesces into a single rebase pass instead of firing one rebase per merge.cancel-in-progress: false(queue) tocancel-in-progress: true(replace), so a new push during the sleep window kills the still-sleeping run and the fresh push gets its own timer.github.event_name == 'push'soworkflow_dispatchruns (urgent manual rebase) skip the wait entirely.Why
Currently every push to
devtriggers an immediate rebase across all open PRs. Each rebased head fires that PR's build pipeline. With 5 open PRs and 3 merges in a few minutes, that's 15 PR-build firings — the per-PRcancel-in-progressonpr-checks.yamlcancels back-to-back builds on the same PR head but can't help across PRs. CI ends up doing a lot of work that the next merge invalidates a minute later.The 30-minute debounce makes CI load proportional to landings-per-half-hour rather than landings × open-PR-count.
Behavior matrix
workflow_dispatch(manual urgent)Test plan
dev. Confirm theAuto-rebase open PRsworkflow run enters theDebounce dev-push stormsstep and sits insleep 1800for the configured 30 min before proceeding to checkout.dev. Confirm the first run reports cancelled and a second run starts with a fresh debounce.gh workflow run "Auto-rebase open PRs" --ref devand confirm the debounce step is skipped (manual dispatch).dev(same coverage as today).🤖 Generated with Claude Code