This post is also on the bors.tech website
The central principle of bors-ng is to be an easy-to-set-up implementation of an uncomplicated continuous testing regime, and to do that one thing well. It doesn't take care of deployment, it doesn't sort your issues, it doesn't update your dependencies, and it doesn't post a comment on all first-time contributors' pull requests.
If you want all that stuff, you can add more apps to do it. And if really want to make it look pro, you can do what bundler did.
This is their greeter script, called bundlerbot:
This is their self-hosted instance of bors-ng, also called bundlerbot:
Making that work required three changes to the usual bors-ng setup.
- The authentication details --- the app ID, private key, and webhook secret --- were kept the same between the GitHub App configuration, the greeter bot, and their self-hosted bors-ng.
- The command trigger was changed from
borsto@bundlerbot, after one of their maintainers added an option to change it. - Instead of setting the webhook URL to point at bors-ng directly, they routed their webhooks to a service called Zapier and configured it to re-send all of the webhooks twice: once to bundlerbot-bors, and once to their greeter.
Unfortunately, even though Zapier is nice and flexible, it required them to set all of the headers that needed to be re-sent one at a time: the request body for the forward should be sourced from the request body of the initial request, X-GitHub-Delivery should be pulled from X-GitHub-Delivery in the original request, X-Hub-Signature should be pulled from X-Hub-Signature in the original request, and so on. It's not hard to do, just annoying.
They also set the committer email to the same one that the now-unmaintained bundlerbot-homu used. This all allows them to maintain continuity as they evolve the underlying tech behind their GitHub automation, so no matter what third-party app or custom integration they use, it will always be just another iteration of bundlerbot.
