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
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:
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