Is this a new feature, an enhancement, or a change to existing functionality?
New Feature
How would you describe the priority of this feature request
High
Please provide a clear description of problem this feature solves
CI can break on main even when every PR passed its own checks. Because we don't require rebasing onto the latest main before merge, each PR is only tested against the state of main at the time its branch was created - not against other changes merging around the same time. Two PRs with independently passing, non-conflicting change sets can be merged one after the other and then fail in CI on main, because the combination (change set 1 + 2) is never tested together until it lands. This is a semantic/logical conflict that Git's textual merge can't detect, so it passes review and merge but breaks the build on main.
Feature Description
Adopt GitHub merge queues as the first approach. Rather than merging immediately on approval, an approved PR is added to a Github Merge queue. From there, GitHub builds a temporary candidate branch containing the PR's changes on top of main plus everything already queued ahead of it, runs the required checks against that candidate, and only merges if it passes. This guarantees the exact combination that lands on main was tested as a unit, closing the "1 passes, 2 passes, 1+2 fails" gap without forcing contributors to manually rebase and re-run CI in a race.
Implementation steps:
- Enable the merge queue on
main in branch protection settings.
- Tune queue settings (batch size, max entries, build concurrency) to balance merge throughput against CI cost.
- Update
CONTRIBUTING.md to document the "approve → queue → merge" flow.
Describe your ideal solution
No response
Describe any alternatives you have considered
No response
Additional context
No response
Code of Conduct
Is this a new feature, an enhancement, or a change to existing functionality?
New Feature
How would you describe the priority of this feature request
High
Please provide a clear description of problem this feature solves
CI can break on
maineven when every PR passed its own checks. Because we don't require rebasing onto the latestmainbefore merge, each PR is only tested against the state ofmainat the time its branch was created - not against other changes merging around the same time. Two PRs with independently passing, non-conflicting change sets can be merged one after the other and then fail in CI onmain, because the combination (change set 1 + 2) is never tested together until it lands. This is a semantic/logical conflict that Git's textual merge can't detect, so it passes review and merge but breaks the build on main.Feature Description
Adopt GitHub merge queues as the first approach. Rather than merging immediately on approval, an approved PR is added to a Github Merge queue. From there, GitHub builds a temporary candidate branch containing the PR's changes on top of
mainplus everything already queued ahead of it, runs the required checks against that candidate, and only merges if it passes. This guarantees the exact combination that lands onmainwas tested as a unit, closing the "1 passes, 2 passes, 1+2 fails" gap without forcing contributors to manually rebase and re-run CI in a race.Implementation steps:
mainin branch protection settings.CONTRIBUTING.mdto document the "approve → queue → merge" flow.Describe your ideal solution
No response
Describe any alternatives you have considered
No response
Additional context
No response
Code of Conduct