Description

ShaharNaveh

opened on May 17, 2026

Issue body actions

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

1. ShaharNaveh

   added

   RFCRequest for commentsRequest for comments

   on May 17, 2026
2. ShaharNaveh commented on May 17, 2026

   

   ShaharNaveh

   on May 17, 2026

   ContributorAuthor

   More actions

   cc: @youknowone @fanninpm @coolreader18
3. youknowone commented on May 28, 2026

   

   youknowone

   on May 28, 2026

   Member

   More actions

   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.

   1. I can select merge/squash/rebase now, but forcing merge queue lose that feature. (not sure if now fixed or not)
   2. We don't have enough CI capacity. That critically slows down merge by everything runs CI one more time.
4. ShaharNaveh commented on May 28, 2026

   

   ShaharNaveh

   on May 28, 2026

   ContributorAuthor

   More actions

   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.

   1. I can select merge/squash/rebase now, but forcing merge queue lose that feature. (not sure if now fixed or not)

   If we can't do a squash merge that's a deal breaker, but I do believe that is possible today.

   3. We don't have enough CI capacity. That critically slows down merge by everything runs CI one more time.

   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

Issue actions