Switch from Bors to GitHub Merge Queues

[metasim]

Bors is going away:

The geo team has converted their repo to use GitHub Merge Queues. Seems like following their lead and not having to host our own bors infrastructure is the easiest path forward.

Per this discussion, we can use the following as references for the migration:

• georust/geo#1037
• georust/proj#179 (comment)

We will need to determine the process impacts, i.e. what do we need to change in the way we review, accept, and merge PRs.

[michaelkirk]

Some notes from the geo transition to merge queues (which seem to be working fine BTW).

They are my own notes and might not be 100% correct:

Within repo > settings > branches

You need a branch protection rule for the main branch.

Then you need to apply at least these settings:

status checks

You need to enter every status check and keep this list in sync as you add/remove jobs, just like you have been with your bors.toml. Note that the geo repo only lists one status check because we have an aggregate job that combines all the other jobs.

enable merge queue

add merge_group to your workflow triggers (inside the on key)

 on:
   push:
     branches:
       - main
       - staging
       - trying
       - release/**
   pull_request:
+  merge_group:

e.g. in geo

TBH I found the transition surprisingly complicated, but it was mostly due to an arbitrary detail in how we implemented our aggregate ci result job (fixed here).

The short version is: A GH status can pass, fail, or be skipped. Our aggregate job would be skipped if any of the sub-jobs failed. I actually never realized this and assumed it would fail. But it didn't matter because bors considered a skip as a failure. GH merge-queues did the opposite - it would proceed when it's status check was "skipped".

Ultimately it didn't require a big change, but took me an annoyingly long time to figure out what the issue was. And since it doesn't look like you have an aggregate job it shouldn't affect you anyway.

Good luck!

[metasim]

bors considered a skip as a failure. GH merge-queues did the opposite - it would proceed when it's status check was "skipped".

I'm willing to bet this insight alone will save one of us days of insanity! 😅