Use GitHub Merge Queues instead of Bors

[james7132]

What problem does this solve or what need does it fill?

GitHub now supports Merge Queues, which is what bors has been doing for us for the longest time.

What solution would you like?

Migrate to GitHub's merge queue instead of relying on Bors.

What alternative(s) have you considered?

Keep using Bors.

[james7132]

We probably should wait until 0.10 releases before we attempt this.

[superdump]

What benefits/drawbacks are there of changing to GitHub/continuing with bors?

[james7132]

AFAIK, GitHub's are publicly viewable and each attempt is public information, unlike bors where the permissions to view the queue are also the same that allows use of bors r+. It also minimizes the attack surface in the case bors is compromised for whatever reason. Not sure if there are Actions triggers for each queue attempt, but if there are, we can have tighter control and integration with our existing CI actions.

It does, however, increase our dependence on GitHub as a platform, and we'd need to find a suitable replacement if we ever move away from GitHub for whatever reason. However, given that our Q&A is in Discussions and our extensive CI use is entirely built on GitHub Actions, I think it's probably OK to switch.

Also we won't see the [Merged by Bors] edits on PR titles, and PRs will get "merged" status instead of "closed". This really only has an impact on PR search, the visuals on the site, and the occasional achievement on the site. Not super important, or critical to the project, but probably worth mentioning. When they rolled out, I've saw some complaints that contributors haven't been getting "PRs merged" achievements because of bors. 🤣

[charleskawczynski]

Hello 👋🏻 ,

My team over at CliMA is interested in switching from bors to the GitHub merge queue (GHMQ), however, it seems that GHMQ requires at least two serially run CI cycles before merging. Our CI is a bit long (~1 hr) and doubling the time is painful.

I wanted to know, have you run into this issue as well?

[mockersf]

Hi @charleskawczynski!

Yup, same for us. The merge queue uses branch protection rules, so it means the same jobs must pass once on the PR, and once in the merge queue.

We improved by:

• parallelising as much as possible our jobs, to get fast feedbacks on a PR. If I remember correctly, with our current parallelisation GitHub actions can run on two PRs at a time, after that we reach the maximum number of free executors. It's a choice between faster feedback on an individual PR, or faster start on a group of PR
• splitting our checks in two groups. One that must pass on every update, on that must pass only on the merge queue. The second group is made of jobs that are less likely to fail if the first one pass and may take longer, but we still want to have their status

The first group, in https://github.com/bevyengine/bevy/blob/main/.github/workflows/ci.yml, takes around 15 minutes to run, but would take 1 hour if all were done sequentially, see here for example run.
The second group, in https://github.com/bevyengine/bevy/blob/main/.github/workflows/validation-jobs.yml (see this line to have it not run on PR update), takes 20 minutes to run, but would take 65 minutes to run sequentially. here is an example run.