Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Switch from Homu to Bors mergebots #6703
What was the end-user problem that led to this PR?
Our existing @bundlerbot mergebot is run by bundlerbot-homu, which is a fork of japaric/homu-on-heroku, which is a fork of servo/homu, which is a fork of barosl/homu. Sadly, most of those forks are now unmaintained, including ours. Also, Homu sets up a list of users who are allowed to approve PRs with a list in a file on an env var, when it probably should just read the list of github users that have the permission to merge.
So the end-user problem is: unmaintained mergebot, very inconvenient to update team members.
What was your diagnosis of the problem?
My diagnosis is that we should migrate from a Homu-based mergebot to a bors-ng-based mergebot. Bors-ng lives at bors-ng/bors-ng, and has a website at bors.tech. Bors-ng is actively maintained, easy to deploy to Heroku, doesn't lose repo and PR state when the webapp is restarted, and uses GitHub permissions to determine who can approve PRs for merging.
What is your fix for the problem, implemented in this PR?
My fix for this problem was to fork bors-ng to the @bundler organization, modify bors-ng to respond to
The bors-ng repo has already accepted our patch, and we maybe don't even need to keep the forked repo anymore.
The new mergebot lives at https://bundlerbot-bors.herokuapp.com, and has the exact same issue-comment interface as the previous mergebot.
Why did you choose this fix out of the possible options?
I chose this fix because it lets us keep the exact same mergebot interface that we have today, while easing the maintenance burden both on updating end-user permissions and on updating the app over time, since we can simply pull and deploy the latest from