fix(dependabot): fix automerge stall — bypass fallback on update-branch failure + schedule trigger#202
Conversation
…anch fails, add schedule trigger Two bugs prevented Dependabot PRs from automerging: 1. update-branch always called `continue` even on failure. The dependabot-automerge-petry GitHub App lacks the `workflows` permission, so update-branch fails with 403 when main contains workflow file changes. The unconditional `continue` then skipped the merge step permanently, leaving those PRs stuck forever. Fix: move `continue` inside the success branch; on failure fall through to the direct merge attempt. The bypass actor (bypass_mode:always) can call the merge API directly even when the branch is behind, as long as CI passed on the PR head and strict_required_status_checks_policy is false. 2. The rebase workflow only fired on push to main. In repos with no recent merges (e.g. TalkTerm, 3 days without a push), the serialization chain stalled after updating PR branches — no subsequent push triggered the merge step. Fix: add schedule trigger (every 4 hours) as a safety net. Also document both root causes and the required `workflows` permission for the GitHub App in dependabot-policy.md and the standard template. Action required: grant the dependabot-automerge-petry GitHub App the `workflows` permission in GitHub App settings → Permissions → Workflows → Read & Write, then accept the updated permission in each installed repo. Without this, update-branch will still fall back to direct merge (which works via bypass), but bringing branches fully up to date before merging is preferred for cleaner history. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Warning Rate limit exceeded
To continue reviewing without waiting, purchase usage credits 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: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (4)
📝 WalkthroughWalkthroughThe PR adds a 4-hour scheduled trigger to Dependabot rebase workflows as a safety net against queue stalling, improves error handling when the update-branch API call fails (by documenting permission/conflict scenarios and falling back to direct merge), and updates policy documentation and setup checklist to reflect these requirements and behaviors. ChangesDependabot Automation Safety Net and Error Handling
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related issues
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)
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. 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 pull request fixes a Dependabot automerge stall in the org’s Dependabot rebase/merge workflow by ensuring merge attempts aren’t skipped after an update-branch failure, and adds a scheduled trigger to prevent the merge queue from stalling when main has no recent pushes.
Changes:
- Adjusts the reusable workflow control flow so
continuehappens only whenupdate-branchsucceeds; failures now fall through to the merge readiness checks and merge attempt. - Adds a
scheduletrigger (every 4 hours) to both the standard caller stub and this repo’s caller stub to drain merge-ready PRs even withoutpushevents. - Updates Dependabot policy documentation to describe the new behavior and the GitHub App permission requirement.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
standards/workflows/dependabot-rebase.yml |
Adds a scheduled trigger and updates the “do not remove triggers” guidance in the template stub. |
standards/dependabot-policy.md |
Documents the workflows permission requirement and the new scheduled safety-net trigger; describes fallback behavior when update-branch fails. |
.github/workflows/dependabot-rebase.yml |
Adds the scheduled trigger to this repo’s caller stub so merges can proceed even without pushes to main. |
.github/workflows/dependabot-rebase-reusable.yml |
Fixes control flow so update-branch failure no longer permanently skips merge attempts. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| on: | ||
| push: | ||
| branches: | ||
| - main | ||
| schedule: | ||
| - cron: '0 */4 * * *' # every 4 hours — safety net when no pushes to main trigger the chain | ||
| workflow_dispatch: # allow manual trigger to flush Dependabot PR queue |
| # Fall through to the merge attempt — the bypass actor (bypass_mode:always) | ||
| # can merge directly even when the branch is behind, provided the PR's | ||
| # own CI has already passed and the strict_required_status_checks_policy | ||
| # is false (which it is for this org). | ||
| echo " Warning: could not update branch for PR #$PR_NUMBER — will attempt direct merge" |
| permanently. The bypass actor (`bypass_mode: always`) can call `gh api .../merge` | ||
| directly even when the branch is behind `main`, as long as the PR's own CI has | ||
| passed and `strict_required_status_checks_policy` is `false`. |
GitHub evaluates bypass actors per-ruleset. A bypass actor in pr-quality does NOT carry over to protect-branches or a 'main' ruleset on the same branch. If multiple rulesets target main and any of them has a pull_request or required_status_checks rule without the app bypass, the merge API call is rejected even though pr-quality allows the bypass. Root cause of the automated merge failures we saw: .github has a protect-branches ruleset and TalkTerm has a main ruleset, both with only Admin-role bypass. Adding dependabot-automerge-petry to these rulesets (requires a classic PAT or GitHub UI — not possible with the default OAuth token) will allow the rebase workflow's direct merge calls to succeed. As a workaround the current backlog was cleared manually using admin token. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
standards/workflows/dependabot-rebase.yml (1)
47-47:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winUpdate template SHA to match the re-tagged v1 — template is stale after merge.
The v1 tag now points to
02ce89b...(verified via GitHub API), but the template still pins the pre-fix SHAb51e2edf.... Since repos are meant to copy this template verbatim, they'll call the buggy reusable workflow. Update line 47 to pin the new SHA that v1 now references, or explicitly document when a follow-up PR will do so.🤖 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 `@standards/workflows/dependabot-rebase.yml` at line 47, The reused workflow SHA pinned in the uses statement ("uses: petry-projects/.github/.github/workflows/dependabot-rebase-reusable.yml@b51e2edf830ea085be0277bcf3174c7b3ec8f958") is stale; update that commit hash to the new SHA that the v1 tag now points to (replace b51e2edf830ea085be0277bcf3174c7b3ec8f958 with 02ce89b...) so the workflow uses the fixed template, or alternatively add a follow-up note in the file documenting that a later PR will update the SHA to match v1.
🤖 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.
Outside diff comments:
In `@standards/workflows/dependabot-rebase.yml`:
- Line 47: The reused workflow SHA pinned in the uses statement ("uses:
petry-projects/.github/.github/workflows/dependabot-rebase-reusable.yml@b51e2edf830ea085be0277bcf3174c7b3ec8f958")
is stale; update that commit hash to the new SHA that the v1 tag now points to
(replace b51e2edf830ea085be0277bcf3174c7b3ec8f958 with 02ce89b...) so the
workflow uses the fixed template, or alternatively add a follow-up note in the
file documenting that a later PR will update the SHA to match v1.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 84576308-5721-4727-8f88-7b53bbc7cc1b
📒 Files selected for processing (4)
.github/workflows/dependabot-rebase-reusable.yml.github/workflows/dependabot-rebase.ymlstandards/dependabot-policy.mdstandards/workflows/dependabot-rebase.yml
Move the bypass-actors rule out of a buried blockquote under `pr-quality` into its own top-level section that applies to every ruleset targeting main. Adds: canonical bypass-actors table, explanation of why `always` is required, API snippet for adding the bypass actor to an existing ruleset, and a compliance-check bash one-liner to audit all repos. Removes: the two buried Critical blockquotes under `pr-quality` which were easy to miss when creating additional rulesets (protect-branches, main, etc.), replaced with a cross-reference to the new top-level section. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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 `@standards/github-settings.md`:
- Around line 159-160: The repo enumeration is capped by "--limit 50" causing
missed repos; update the loop that uses "gh repo list petry-projects --json name
--jq '.[].name' --limit 50" to fetch all repos (e.g., remove the explicit 50
limit or use "--limit -1" / proper pagination) so the for loop over "repo"
iterates the entire org, and keep the subsequent ruleset call that uses "gh api
\"repos/petry-projects/$repo/rulesets\" --jq '.[].id' 2>/dev/null" unchanged
except for any necessary rate‑limit handling when processing a larger result
set.
🪄 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: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: fb174a0a-1a95-4402-8974-c81498e58ec9
📒 Files selected for processing (1)
standards/github-settings.md
- dependabot-rebase.yml: fix AGENTS comment to list all three required triggers (push + schedule + workflow_dispatch) and explain each - dependabot-rebase-reusable.yml: clarify fallback merge comment — note that it only works when strict_required_status_checks_policy is false; when strict is enforced, granting the App the workflows permission is required - dependabot-policy.md: same clarification in Fallback merge section - github-settings.md: raise --limit to 1000 in compliance check so it covers orgs with >50 repos; remove pull_request/required_status_checks filter so every ruleset missing the bypass is reported, not just those with specific rule types Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|



Summary
Two bugs were preventing Dependabot PRs from automerging:
Bug 1:
update-branchfailure permanently blocked the merge stepThe
dependabot-automerge-petryGitHub App lacks theworkflowspermission. Whenmaincontains changes to.github/workflows/*.ymlfiles, theupdate-branchAPI call fails with 403. The old code always calledcontinueafter the update-branch attempt — whether it succeeded or failed — skipping the merge step permanently.Fix: Move
continueinside the success branch. When update-branch fails, fall through to the direct merge attempt. The bypass actor (bypass_mode: always) can call the merge API directly even when the branch is behind, as long as CI passed on the PR head andstrict_required_status_checks_policyisfalse.Affected right now: PR #178 (
actions/checkout-6.0.2) stuck for 4+ days — 5 commits behind becausee5ef191changed a workflow file, causingupdate-branchto fail on every rebase run.Bug 2: Serialization chain stalled without pushes to main
The rebase workflow only fired on
push: main. In repos without recent merges (TalkTerm: 3 days with no push to main), updated PR branches would sit with CI passing but no trigger to run the merge step.Fix: Added
schedule: cron: '0 */4 * * *'as a safety net. Every 4 hours the workflow checks for merge-ready PRs and drains the queue.Action required from repo owner
Grant
workflowspermission to thedependabot-automerge-petryGitHub App:Then accept the updated permission in each installed repo. Without this,
update-branchwill continue to fall back to direct merge (which works via bypass), but keeping branches up-to-date before merging is cleaner.Follow-up
v1tag updated to02ce89b— TalkTerm picks up the fix automaticallybroodly,markets,google-app-scripts,ContentTwin) pinning the old SHA will follow🤖 Generated with Claude Code
Summary by CodeRabbit
Chores
Documentation