Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch from Bors to GitHub Merge Queues #452

Open
metasim opened this issue Oct 4, 2023 · 2 comments
Open

Switch from Bors to GitHub Merge Queues #452

metasim opened this issue Oct 4, 2023 · 2 comments

Comments

@metasim
Copy link
Contributor

metasim commented Oct 4, 2023

Bors is going away:

image

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:

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
Copy link
Member

michaelkirk commented Oct 4, 2023

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

Screenshot 2023-10-04 at 10 22 31

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

Screenshot 2023-10-04 at 10 22 20

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
Copy link
Contributor Author

metasim commented Oct 4, 2023

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! 😅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants