Clarifying merge queue behavior with "Only merge non-failing pull requests" disabled #180420
Replies: 3 comments
-
|
🕒 Discussion Activity Reminder 🕒 This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions: 1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as 2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own. 3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution. Note: This dormant notification will only apply to Discussions with the Thank you for helping bring this Discussion to a resolution! 💬 |
Beta Was this translation helpful? Give feedback.
-
|
hey, that setting definitely complicates things. here is how the logic actually handles those specific scenarios: for Q1 (ejection): you are correct. when that setting is disabled, the queue keeps a failing PR only if it is part of a group where a later PR might fix the build. once you removed the PR behind it, the failing PR became the "tip" with no potential fix following it, so the queue ejected it immediately. for Q2 (grouping): groups are processed sequentially. if Group A (1+2+3) fails, the queue does not wait for Group B. it immediately stops and enters "bisection" mode—it splits Group A up (e.g. tries just 1+2) to identify exactly which PR broke the build. Group B basically gets reset because its base commit is now invalid. for Q3 (mixed results): the queue tests the final state of the group. if you have [1, 2, 3] in a group and the combined build fails (because of #3): the entire group is marked as failed. the queue bisects/splits them. it will likely attempt to run [1+2]. if that passes, those merge, and #3 is isolated and ejected. basically, it only tolerates failure if the final commit of the group passes CI. hope that clears it up! |
Beta Was this translation helpful? Give feedback.
-
|
🕒 Discussion Activity Reminder 🕒 This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions: 1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as 2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own. 3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution. Note: This dormant notification will only apply to Discussions with the Thank you for helping bring this Discussion to a resolution! 💬 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Select Topic Area
Question
Body
I'm trying to understand exactly how merge queue handles failures when "Only merge non-failing pull requests" is disabled, particularly around group formation and PR ejection.
My understanding:
With the setting disabled, only the last PR in a group needs to pass for the group to merge
This is useful for flaky tests since a passing "last PR" validates the combined changeset
What I'm unclear on:
Question 1: When does a failing PR get ejected? I observed that a failing PR was removed from the queue after I manually removed the only PR behind it. This suggests "keep failing PRs around as long as there's a later PR that might pass." Is that accurate?
Question 2: How do groups interact with ejection? If max group size is 3:
Group A: PR #1, #2, #3
Group B: PR #4, #5, #6
If all 3 PRs in Group A fail, does the queue remove PR #1 from Group A once it's full? Or does it wait for Group B to also fail as long as those checks are still running?
The "Failing CI" section only describes behavior when "Only merge non-failing pull requests" is enabled. What happens when it's disabled and the last PR in the queue fails? Does it eventually get ejected, or does it persist as long as new PRs keep joining?
Question 3: Same scenario but PR #1 fails, PR #2 passes, PR #3 fails. What happens and when?
Trying to find the right balance between tolerating flaky tests and ensuring real bugs get ejected in a reasonable timeframe.
Beta Was this translation helpful? Give feedback.
All reactions