Conversation
…dations ## Summary Analysis of Dependabot auto-merge workflow reveals policy is correctly implemented but repository rulesets cause operational stalling. The `require_last_push_approval` setting, combined with `required_linear_history`, creates a rebase loop that prevents Dependabot PRs from merging even when approved and checks passing. ## Changes 1. Add DEPENDABOT_STATUS_ANALYSIS.md — comprehensive investigation report: - Confirms auto-merge workflow works correctly for GitHub Actions (including MAJOR bumps) - Documents root cause: ruleset interaction with rebase workflow - Provides tactical and strategic recommendations - Answers user questions about hourly review workflow (none exists—approvals are event-driven) 2. Update standards/github-settings.md: - Clarify rationale for `require_last_push_approval: false` - Document interaction with Dependabot auto-merge workflow - Add reference to dependabot-policy.md for full context ## Key Findings ✅ Dependabot auto-merge workflow: Working as designed ✅ Policy document: Correct and complete ❌ Operational issue: PRs stuck BEHIND due to ruleset constraints⚠️ Proposed fix: Change `require_last_push_approval: false` (see analysis for details) ## Recommendations 1. Tactical: Use `@dependabot recreate` for edited PRs (PR #125) 2. Strategic: Relax ruleset constraint to unblock auto-merge flow 3. Process: Update AGENTS.md with Dependabot troubleshooting guide See DEPENDABOT_STATUS_ANALYSIS.md for full details, timeline, and alternatives. Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 21 minutes and 13 seconds. ⌛ 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 (2)
✨ 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 |
|
…k merge ## Problem When dependabot-rebase updates a PR branch (after it falls behind main), the update counts as a "push" event. GitHub's `dismiss_stale_reviews_on_push` rule then marks the PR's approval as stale, preventing merge even though: - ✅ PR branch is now current - ✅ Approval exists - ✅ All checks pass Result: PR stuck BLOCKED/BEHIND indefinitely. ## Solution (Option C: Workflow Fix, Not Ruleset Change) After updating a Dependabot PR branch, immediately re-approve it using the app-bot token. This maintains the `require_last_push_approval: true` safeguard for human developers while unblocking Dependabot's automated workflow. This is safe because: - Re-approval is after a branch-only update (no code change) - Bot-to-bot approval is expected and trusted - Human-authored PRs keep their safeguard intact ## Changes 1. **dependabot-rebase-reusable.yml**: Add re-approval step after update-branch - Checks if update succeeded - Re-approves the PR with explanatory comment - Continues to next PR in queue - No behavior change if re-approval fails (PR still queued) 2. **standards/github-settings.md**: Revert ruleset change recommendation - Keep `require_last_push_approval: true` - Document that rebase workflow re-approves after updates - No policy change needed 3. **DEPENDABOT_STATUS_ANALYSIS.md**: Update recommendation - Change from "relax ruleset" to "fix workflow" - Recommend Option C as correct solution - Explain why workflow fix is superior ## Testing PR #125 and #129 should now: 1. Be rebased to be current with main 2. Immediately re-approved by the rebase workflow 3. Merge automatically as all requirements are met Expected in PR history: Re-approval comment from app-bot after branch update. Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
✅ Implementing Option C - Workflow Fix (The Correct Solution)After risk analysis, I've implemented Option C: fix the rebase workflow instead of changing the ruleset. This is the correct approach because: Why Option C is Superior
What I've ChangedCommit 5ea14de implements:
How It WorksBefore (stuck in loop): After (self-sustaining chain): Expected Results
TestsOnce merged, test by:
Next StepsThis PR is now ready for review with the corrected implementation. The analysis is solid, the fix is minimal and safe, and it maintains all security safeguards while unblocking Dependabot's workflow. Key Insight: The real mistake would have been changing the ruleset. This was a workflow problem, not a policy problem. The rule itself is valuable for protecting human developers. |
There was a problem hiding this comment.
Pull request overview
Updates Dependabot maintenance guidance and automation to address ruleset interactions that can leave Dependabot PRs blocked after branch updates.
Changes:
- Updates the
pr-qualityruleset documentation to add rationale around “Require last push approval”. - Updates the Dependabot rebase/merge reusable workflow to re-approve PRs after
update-branchsucceeds.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
standards/github-settings.md |
Adjusts ruleset documentation for “Require last push approval” with additional rationale tied to Dependabot workflows. |
.github/workflows/dependabot-rebase-reusable.yml |
Adds post-update-branch re-approval logic intended to refresh approvals after branch updates. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
don-petry
changed the title
…x warning message - Only re-approve after update-branch if auto-merge is already enabled. Auto-merge is set exclusively by the automerge workflow after confirming policy eligibility, preventing inadvertent approval of PRs requiring human review (e.g. major non-Actions updates). - Fix misleading warning: 'may still merge if approval is stale' → 'will remain blocked until manually re-approved' - Add inline comment explaining update-branch authorship w.r.t. require_last_push_approval (pusher = GitHub infra, approver = app) Addresses Copilot review comments on PR #140.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
|
Review — fix requested (cycle 1/3)The automated review identified the following issues. Please address each one: Findings to fix
Additional tasks
The review cascade will automatically re-review after new commits are pushed. |
… caller stubs Reusable workflow permissions are capped by the calling job. Update both the live caller (.github/workflows/dependabot-rebase.yml) and the standards template (standards/workflows/dependabot-rebase.yml) to grant write permissions so the reusable's GITHUB_TOKEN can call update-branch and approve PRs. Also update the pinned SHA to origin/main (35e0e20) which includes the re-approval fix from PR #140.
…P 403 on workflow files * fix(dependabot-rebase): use GITHUB_TOKEN for update-branch, app token for approvals The GitHub App lacks 'workflows' permission, causing update-branch to fail with HTTP 403 when the merge would include .github/workflows/ changes from main. Fix: use GITHUB_TOKEN (which has implicit workflows write permission in push-triggered workflows) for the update-branch call. Reserve the app token for approvals and merges, where the app bot identity matters: - Approvals: attributed to the trusted app bot (satisfies require_last_push_approval since GITHUB_TOKEN was the pusher, not the app) - Merges: attributed to the app bot so the resulting push to main re-triggers this workflow, enabling the self-sustaining serialization chain Also adds contents:write, pull-requests:write, workflows:write permissions to the job so GITHUB_TOKEN can perform these operations. * fix: remove invalid 'workflows' job permission scope (not a valid GHA scope) 'workflows' is a GitHub App permission, not a GitHub Actions job permission scope. actionlint correctly rejects it. GITHUB_TOKEN with contents:write in a push-triggered workflow already handles .github/workflows/ file updates. * fix(dependabot-rebase): grant contents:write + pull-requests:write in caller stubs Reusable workflow permissions are capped by the calling job. Update both the live caller (.github/workflows/dependabot-rebase.yml) and the standards template (standards/workflows/dependabot-rebase.yml) to grant write permissions so the reusable's GITHUB_TOKEN can call update-branch and approve PRs. Also update the pinned SHA to origin/main (35e0e20) which includes the re-approval fix from PR #140. --------- Co-authored-by: DJ <dj@Rachels-Air.localdomain>
* fix(dependabot-rebase): update pinned SHA to include GITHUB_TOKEN fix The caller stubs referenced SHA 35e0e20 (PR #140), which predates the GITHUB_TOKEN change from PR #141. Update to f5c167c (HEAD of main after PR #141 merged) so the reusable workflow used has contents:write/ pull-requests:write job permissions and uses GITHUB_TOKEN for update-branch. * docs: clarify SHA bump is allowed in caller stub header comment The previous header said 'MUST NOT change the uses: line', but bumping the pinned SHA when upgrading the reusable workflow version is intentional and necessary. Clarify what is forbidden vs what is allowed. --------- Co-authored-by: DJ <dj@Rachels-Air.localdomain>
Summary
Fixes Dependabot PRs getting stuck after the rebase workflow updates their branches.
Root cause: When
dependabot-rebasecallsupdate-branch, the push stales any existing approval (dismiss_stale_reviews_on_push: true). The PR is now current but un-approved, so auto-merge cannot proceed.Fix: After a successful
update-branch, re-approve the PR using the app token — but only ifautoMergeRequestis already set. Auto-merge is set exclusively by thedependabot-automergeworkflow after confirming policy eligibility, so this gate prevents accidentally approving PRs that require human review (e.g., major non-Actions updates).Security:
require_last_push_approvalis preserved. Theupdate-branchAPI call creates a merge commit authored by GitHub's infrastructure (not the app token), so the pusher and approver are different identities — the rule is satisfied.Changes
.github/workflows/dependabot-rebase-reusable.yml: Afterupdate-branchsucceeds, check ifautoMergeRequestis set and re-approve if sostandards/github-settings.md: Adds rationale note forrequire_last_push_approvalexplaining the rebase workflow's re-approval behaviourHow it works
Before (stuck):
After (self-sustaining):
Testing
Once merged, the next push to
maintriggersdependabot-rebase, which should:🤖 Generated with Claude Code