Repository navigation
Auto-merge Renovate PRs through the Mergify merge queue - #299
Conversation
Renovate's own automerge (GitHub auto-merge) doesn't wait for the build check, since main has no required checks. Instead, Mergify queues every Renovate PR, rebases it onto main, and merges it with a merge commit once the build check passes, for semi-linear history. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
This pull request does not currently match the merge queue conditions, so it cannot be queued from here. The box comes back if it matches again. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: fad7df4bf2
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| merge_conditions: | ||
| - check-success = build | ||
| # Semi-linear history: rebase the PR onto main, then merge it with a merge commit | ||
| update_method: rebase |
There was a problem hiding this comment.
Configure the queue so the requested rebase actually occurs
update_method: rebase only updates branches when Mergify performs in-place checks, but this queue uses a separate merge_conditions phase and leaves merge_queue.max_parallel_checks at its default of 5, so Mergify instead tests a temporary batch PR and then merges the original, unrebased PR head. Consequently, a Renovate PR created from an older main produces ordinary branching history rather than the semi-linear history promised by the comment. Mergify documents both the in-place-check requirements and that update_method applies to in-place updates; either make the queue eligible for in-place checks or select a method that lands the tested batch branch.
Useful? React with 👍 / 👎.
Renovate's
automergeuses GitHub's auto-merge. Sincemainhas no required checks, that doesn't wait for thebuildcheck added in #297. This moves auto-merging to Mergify:renovate.json: drop theautomergerule. Renovate still opens the PRs but no longer merges them..mergify.yml(new; this repo had none):renovate[bot]is put into thedefaultmerge queue, whatever the update type, majors included.check-success = build.update_method: rebase+merge_method: merge: the PR is rebased ontomainand then merged with a merge commit (semi-linear history), per Mergify's merge strategies docs.PRs from anyone else aren't queued automatically, and manual merges are unaffected.
Not yet verified: how the rebase plays out on a real Renovate PR. In particular, no
update_bot_accountis set, so Mergify rebases through GitHub's API as itself. Most Renovate PRs here touch.github/workflows/pages.yml, and I couldn't find in Mergify's docs whether that matters. The first Renovate PR after merge will show it.🤖 Generated with Claude Code