How bundler combines bors-ng with their own welcome bot


#1

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 bors to @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.


#2

Nice writeup! I will definitely link people to this. :slight_smile:


#3

This great article comes at the right time as I was also looking at writing a bot for our GH projects :slight_smile:

It’s interesting how they used Zapier to duplicate GH webhooks to both bots, but I’m wondering if there’s a limit to the number of requests Zapier will handle in their free tier (I’ve used Zapier in the past, but only with their gmail/gdrive integration).

Perhaps they could have achieved the same by using a reverse proxy that could do shadowing/mirroring? Like http://nginx.org/en/docs/http/ngx_http_mirror_module.html


#4

Alternatively, they could just have used two different webhooks, one for the greeter bot (only hooked to the creation of PRs) and one for bors (which needs way more access).

Did they explain why they opted not to do that? Adding a second webhook to GH is not exactly rocket surgery.


#5

@xmo-odoo I think the difference/reason is that bors and the bot are apps, not just plain webhook recipients