feat: add direct merge to dependabot update workflow#129
Conversation
GitHub auto-merge (--auto) fails to trigger when rulesets cause mergeable_state to report "blocked" despite all requirements being met. Add a direct merge step that checks if PRs are up-to-date with all checks passing, and merges them using the app token. The app token merge triggers a new push to main, creating a self-sustaining chain. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe Dependabot workflow is extended to automatically merge PRs after updating branches. When PRs are up-to-date, the workflow checks auto-merge eligibility, verifies CI status passes, and performs squash merges while limiting one merge per run. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
There was a problem hiding this comment.
Pull request overview
Updates the dependabot-rebase GitHub Actions workflow to not only update behind Dependabot PR branches, but also directly merge the first Dependabot PR that appears merge-ready (up-to-date, auto-merge enabled, and checks passing), using an app token to trigger a push-to-main “chain” of successive merges.
Changes:
- Expand the workflow’s purpose and rename job/step labels to reflect both updating and merging.
- Add logic to detect up-to-date Dependabot PRs with auto-merge enabled and passing checks, then merge one PR per run via the GitHub API.
- Keep update-branch behavior for behind PRs using merge (not rebase) to preserve Dependabot commit identity.
Comments suppressed due to low confidence (1)
.github/workflows/dependabot-rebase.yml:33
- This workflow is designed to "serialize" Dependabot merges via a chain of pushes to
main, but without aconcurrencygroup multiple runs can overlap (e.g., a merge-triggered push starts a new run while the previous run is still iterating PRs). That can lead to parallel merge attempts and defeats the one-at-a-time guarantee. Add a workflow/job-levelconcurrencygroup (withcancel-in-progress: falseto queue) to ensure only one run executes at a time.
on:
push:
branches:
- main
| # still recognizes the PR as its own. | ||
| # Solution: after every push to main (typically a merged PR), this workflow: | ||
| # 1. Updates behind Dependabot PRs using the merge method (not rebase) | ||
| # 2. Merges any Dependabot PR that is up-to-date, approved, and passing CI |
There was a problem hiding this comment.
The header comment says the workflow "merges any Dependabot PR that is up-to-date, approved, and passing CI", but the implementation only checks that auto-merge is enabled and checks are passing (it does not verify reviewDecision/approvals). Either update the comment to match the actual gating, or add an explicit approval check (e.g., reviewDecision == APPROVED) before attempting the merge so behavior matches the documented intent.
| # 2. Merges any Dependabot PR that is up-to-date, approved, and passing CI | |
| # 2. Merges any Dependabot PR that is up-to-date, auto-merge-enabled, and passing CI |
| # Check if all required checks pass (look at overall rollup) | ||
| CHECKS_PASS=$(gh pr view "$PR_NUMBER" --repo "$REPO" \ | ||
| --json statusCheckRollup \ | ||
| --jq '[.statusCheckRollup[]? | select(.name != null and .status == "COMPLETED") | .conclusion] | all(. == "SUCCESS" or . == "NEUTRAL" or . == "SKIPPED")') |
There was a problem hiding this comment.
The jq expression uses all(...) over the list of completed checks; in jq, all on an empty array returns true. If statusCheckRollup is empty (e.g., checks haven't started reporting yet, or the PR has no checks), this would treat the PR as "all checks pass" and attempt to merge. Consider additionally requiring at least one check entry (or using the overall combined status/mergeStateStatus) so merges only happen when CI has actually reported success.
| --jq '[.statusCheckRollup[]? | select(.name != null and .status == "COMPLETED") | .conclusion] | all(. == "SUCCESS" or . == "NEUTRAL" or . == "SKIPPED")') | |
| --jq '([.statusCheckRollup[]? | select(.name != null and .status == "COMPLETED") | .conclusion]) as $completed | ($completed | length) > 0 and ($completed | all(. == "SUCCESS" or . == "NEUTRAL" or . == "SKIPPED"))') |



Summary
mergeable_state: blockedissue where GitHub auto-merge (--auto) never triggers due to rulesets causing a permanent BLOCKED stateHow it works
On each push to main:
Test plan
🤖 Generated with Claude Code
Summary by CodeRabbit