Repository navigation
[RFC] Merge to main by using a merge queue #7903
Description
Summary
Instead of pushing to main when CI pass, we should utilize github's merge queue
Detailed Explanation
ATM, When a PR checks are all passing we merge to main, this has several issues:
- Merge of 2 PRs can break the CI because they were never tested together (i.e. one adds a lint rule, the other violate it)
- Merging many PRs at the same time chokes the CI runners, so there's not available runners for open PRs.
By using merge queues, we can eliminate both issues.
The PR will be marked as "added to merge queue", it will go through the CI (as if it were merged to main), and if it passes it will get merged. other in queue PRs do not trigger the CI until it's their turn.
At the beginning, we can set the parallel builds to 1 to mimic the current behavior
Drawbacks, Rationale, and Alternatives
Unresolved Questions
Reacted by Bas Schoenmaeckers and sunmy2019
Activity
ShaharNaveh commentedon May 17, 2026
cc: @youknowone @fanninpm @coolreader18
youknowone commentedon May 28, 2026
we are using merge queue. we are not forcing merge queue to be perfectly rebased on top of main branch.
I tried to turn on that feature twice, but had a few problems.
ShaharNaveh commentedon May 28, 2026
If we can't do a squash merge that's a deal breaker, but I do believe that is possible today.
I'm not sure what you mean by "one more time", but the idea is to not trigger the CI on push to main, only from the merge queue. so it's a 1:1 replacement, we do not add another CI run.
So there will a little adjustment that needs to be done to our CI triggers