It’s another monthly burst of news about bors, the bot that tests your code before it becomes the master.

In the last month, we landed 18 PRs in the bors-ng repository.

Breaking change: read/write access to issues required

Bors now requires write access to issues, where it originally required only read access. Enabling write access to issues is required for it to close the pull request after merging it, which has been a longstanding issue.

Since the set of permissions required by an integration cannot be changed on-the-fly, a second public instance of bors has been set up. The old instance will be kept up until 7 April, to give users a chance to migrate over.

Migrating over is done by removing your repository from the old instance, then adding it to the new instance. This preserves the contents of your bors.toml files, which contains the CI configuration itself, but does not preserve the list of reviewers.

More information in this blog post.

Edit 27 July 2017: GitHub changed the URL of an Integration/App from github.com/integration to github.com/apps. This page was changed to reflect that, and remove a link to the old integration (which has now been completely removed).

Notable Additions

  • Refactored into an umbrella app
  • Plugged a timer leak, keeping the batcher at one-poll-per-hour
  • Made the batcher supervisor clear the queue if the batcher crashes, preventing transient bad state from causing an infinite loop
  • Include the reviewer’s name in the merge commits. Also add the ability to list other reviewers with the r=someone-else syntax
  • Changed the set of required permissions
  • Corey Farwell (frewsxcv) added an edit button to the Repositories screen
  • Blocked private repositories from being added to the public instance

New Contributors

Want to see your name in this newsletter? Look at bors starters, a curated list of issues that are good for new contributors!

Who’s using bors?

We (@nubisonline, http://nub.is/) are using it in a couple of our larger projects.

Our main use case is this: We have quite a large number of feature branches being worked on simultaneously, and a deployment procedure that takes rather long (~40 mins). We also have the policy that feature branches need to have the master merged into them before they can be merged back.

This results in a project manager having several tabs of PRs open during the day, merging one that is tested and green, then merging the master into the next one, waiting, merging that one once it becomes green, etc (with each of these steps taking the ~40 minutes).

With bors, we just mark all the ones that are green, and bors takes care of merging them in the right order and checking if merging master in it doesn’t break things.

In fact, this had gotten so annoying that I had ‘build a queuing system for PRs’ rather high on my to do list when I found bors :)

One of the projects we’re using it for is live here: https://privatelease.peugeot.nl/, https://privatelease.citroen.nl/, a car configure app for Peugeot/Citroën

This was written by Tim van Dalen, software developer at Nubis Digital Agency. @timvdalen is also one of the earliest adopters of bors-ng, and a prolific bug reporter.

Got any suggestions for next month’s featured user? Post them in the pull request for next month’s TMIB!.

Screenshot

No screenshot to show off this month. Got any suggestions for next month? Post a comment on the TMIB-04 pull request.