ci(mergify): require 2 approvals for large PRs#888
Conversation
Add a separate queue rule for PRs that exceed size thresholds, requiring two approvals instead of one. A PR is considered large if it modifies more than 10 files or adds/deletes more than 500 lines. Normal PRs continue to require only 1 approval. Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com> Signed-off-by: Martin Prpič <mprpic@redhat.com>
WalkthroughConfiguration changes to Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan for PR comments
Comment |
| - "#files>10" | ||
| - "#added-lines>500" | ||
| - "#deleted-lines>500" | ||
| actions: |
There was a problem hiding this comment.
Yeah, we probably needed these action stanzas to make the UI clearer about what it's doing.
|
Let's try it |
|
@Mergifyio queue |
Merge Queue Status
Required conditions to enter a queue
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.mergify.yml:
- Around line 24-42: The .mergify.yml contains a redundant pull_request_rules
block that duplicates queue routing logic; remove the entire pull_request_rules
section (the "pull_request_rules:" key and its two entries "queue large PRs" and
"queue normal PRs") and rely on the existing queue_rules entries with autoqueue:
true and their queue_conditions to handle queuing; if different size-based
behavior is later required, implement it via distinct queue_rules or refined
queue_conditions rather than reintroducing pull_request_rules.
- Around line 27-30: Replace the per-direction size checks with a total-churn
check: in the rule that uses the "- or:" group containing "#files>10",
"#added-lines>500", and "#deleted-lines>500" change the two conditions
"#added-lines>500" and "#deleted-lines>500" to a single "#changes>500" condition
(so the rule triggers on total added+deleted > 500); likewise update the
corresponding normal-PR rule that currently uses "#added-lines<=500" and
"#deleted-lines<=500" to use "#changes<=500" instead, ensuring both "queue large
PRs" and "queue normal PRs" use `#changes` for the 500-line threshold.
| pull_request_rules: | ||
| - name: queue large PRs | ||
| conditions: | ||
| - or: | ||
| - "#files>10" | ||
| - "#added-lines>500" | ||
| - "#deleted-lines>500" | ||
| actions: | ||
| queue: | ||
| name: large-pr | ||
|
|
||
| - name: queue normal PRs | ||
| conditions: | ||
| - "#files<=10" | ||
| - "#added-lines<=500" | ||
| - "#deleted-lines<=500" | ||
| actions: | ||
| queue: | ||
| name: default |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
🧩 Analysis chain
🌐 Web query:
In Mergify, does a pull_request_rulesrule withactions: { queue: ... }automatically enqueue every matching pull request, or only route pull requests after a user has explicitly requested merge/queue? How does this interact withautoqueue: trueinqueue_rules?
💡 Result:
-
A
pull_request_rulesrule withactions: {queue: ...}will enqueue automatically as soon as the rule’sconditionsmatch (it’s not gated on a user “requesting merge/queue”). The docs’ own example says “any pull request that has the labelqueue-mewill be automatically queued.” However, the PR still must satisfy the target queue’squeue_conditionsto actually enter the queue. [1] -
autoqueue: truein aqueue_rulesentry is a separate, more direct mechanism: as soon as a PR matches that queue rule’squeue_conditions, Mergify automatically adds it to the queue—nopull_request_rulesqueueaction and no manual “queue” command is required. [2][3] -
Interaction:
- If
autoqueue: truefor the relevant queue, you usually don’t need anactions: queuerule at all (it becomes redundant unless you want extra gating/logic beyond what you can express inqueue_conditions). [1][3] - If
autoqueue: false(default), then PRs won’t be enqueued just by matchingqueue_conditions; they must be queued explicitly (e.g., via anactions: queuerule or a manual queue command). [2][3]
- If
Sources: Mergify docs on the queue action [1], queue rules / autoqueue behavior [2], and the autoqueue changelog announcement [3].
🏁 Script executed:
cat .mergify.ymlRepository: ambient-code/platform
Length of output: 1128
Remove the redundant pull_request_rules and rely on queue_rules with autoqueue: true.
These pull_request_rules are unnecessary—both queues already have autoqueue: true enabled, which will automatically queue PRs as soon as queue_conditions are met. The size-based routing (large vs. normal) is duplicating that behavior. The queue_conditions (approvals, checks, CodeRabbit comment) provide the actual gating, so queued PRs won't merge until those are satisfied.
Simplify by removing the pull_request_rules entirely. If different size-based logic is needed beyond what queue_conditions can express, reconsider whether separate queues are the right design. Otherwise, a single queue with appropriate conditions is cleaner.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.mergify.yml around lines 24 - 42, The .mergify.yml contains a redundant
pull_request_rules block that duplicates queue routing logic; remove the entire
pull_request_rules section (the "pull_request_rules:" key and its two entries
"queue large PRs" and "queue normal PRs") and rely on the existing queue_rules
entries with autoqueue: true and their queue_conditions to handle queuing; if
different size-based behavior is later required, implement it via distinct
queue_rules or refined queue_conditions rather than reintroducing
pull_request_rules.
| - or: | ||
| - "#files>10" | ||
| - "#added-lines>500" | ||
| - "#deleted-lines>500" |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
What Mergify condition should be used to match a pull request whose total line churn (additions + deletions) exceeds 500? Please check the current Mergify condition syntax for pull request rules.
💡 Result:
Use the #changes condition and compare it numerically:
conditions:
- "#changes > 500"This matches pull requests whose total “lines changed” (line churn) exceeds 500. [1][2]
🏁 Script executed:
cat -n .mergify.yml | sed -n '20,45p'Repository: ambient-code/platform
Length of output: 738
Use #changes to enforce a single 500-line threshold instead of separate per-direction checks.
Lines 27–30 trigger "queue large PRs" only if additions or deletions individually exceed 500 lines. A PR with 300 added and 300 deleted lines (600 total churn) will match lines 37–39 instead, routing to the "default" queue. Replace the separate #added-lines and #deleted-lines conditions with #changes > 500 to catch all PRs exceeding the intended total-churn threshold.
Also applies to: 37–39 (use #changes <= 500 in the "queue normal PRs" rule).
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.mergify.yml around lines 27 - 30, Replace the per-direction size checks
with a total-churn check: in the rule that uses the "- or:" group containing
"#files>10", "#added-lines>500", and "#deleted-lines>500" change the two
conditions "#added-lines>500" and "#deleted-lines>500" to a single
"#changes>500" condition (so the rule triggers on total added+deleted > 500);
likewise update the corresponding normal-PR rule that currently uses
"#added-lines<=500" and "#deleted-lines<=500" to use "#changes<=500" instead,
ensuring both "queue large PRs" and "queue normal PRs" use `#changes` for the
500-line threshold.
There was a problem hiding this comment.
No such things as a #changes condition. Get a hold of yourself, rabbit!
There is modified-lines, but it's not clear how that's computed (is it added+deleted?).
There was a problem hiding this comment.
Whenever this thing goes wrong, I always give it a 👎. Feel free to do the same. Best part of my day
Merge Queue Status
This pull request spent 10 seconds in the queue, with no time running CI. Required conditions to merge
|
2 participants
Add a separate queue rule for PRs that exceed size thresholds, requiring two approvals instead of one. A PR is considered large if it modifies more than 10 files or adds/deletes more than 500 lines. Normal PRs continue to require only 1 approval.
The thresholds I chose (500 lines, 10 files) are pretty arbitrary and up for discussion.