Announcing Pull Request Support

Konstantin Haase,

Josh and José at Railsberry
Josh and José at Railsberry

Some of our team just got back from two pretty intense weeks of conferencing. We had an amazing time speaking at the JAX, Railsberry and RailsConf and getting our hands on two of the Ruby Hero Awards. A couple of announcements were made live on stage and you might have heard a few rumors coming out of the conferences. So let me wrap up one of them for you.

I'm pretty excited about this one, as I've been working on it over the last weeks. This is the first feature to be sponsored by our impressing Love Campaign. While the promise of adding more languages actually came true, this was mainly done by excellent community contributions and the hard working Michael Klishin.

How We Use Pull Requests

A typical Pull Request
A typical Pull Request

When GitHub first announced Pull Requests 2.0, it wasn't obvious right away how truly amazing this feature is for us developers.

Pull Request 2.0 Workflow
Pull Request 2.0 Workflow

It revolutionized the workflow by making the patches part of the discussion. This actually led to code reviews from other contributors while working on a feature, rather than once you think you're done working on it.

Think of it as bringing agile development to Open Source contributions. Wikipedia even calls this new and social approach The GitHub revolution.

It really only had one downside: Merging still was as complicated as before. You have all the fancy review tools and still have to go into the terminal and type a couple of commands. This quickly became rather tedious.

The Merge Button

GitHub's Merge Button allows merging Pull Request from the web interface
GitHub's Merge Button allows merging Pull Request from the web interface

GitHub, once more, came to our rescue by adding the Merge Button.

The Merge Button Workflow
The Merge Button Workflow

By pressing a button on the website, one could easily merge Pull Requests without having to drop to the console.

This feature, combined with the Fork and Edit button, made contributing a no brainer.

Especially the round-trip time for documentation fixes, like typos, broken examples, etc. went down to sometimes just a few seconds.

Contributing a fix became as simple as two clicks on GitHub. Making contributions that easy lowers the barrier and thereby strengthens the Open Source ecosystem.

You probably can tell by now how much we love this feature.

The Merge Button is a dangerous tool, trust Boromir.
The Merge Button is a dangerous tool, trust Boromir.

There is a downside, though. The Merge Button is not really usable for anything but documentation.

If you click the Merge Button for anything touching code, you risk breaking upstream. Maybe this seems acceptable at first, after all your CI will tell you if you broke anything. You are using CI, right?

However, it not only renders your mainline pretty unstable, it also changes responsibility. All of a sudden you as a maintainer are responsible for fixing the issue, if only by reverting the commits.

So you're back at merging locally and checking out if everything works. Maybe you even push on a feature branch first, just to trigger a CI run before merging.

Enter Travisbot

The Perfect™ Workflow
The Perfect™ Workflow

It would be really cool to just know if the Pull Request breaks anything, without all the hassle.

This is basically what we've implemented. We test every mergeable Pull Request and have our friendly Travisbot leave a comment in the Pull Request discussion.

That way you can now safely press the Merge Button. That is, if it doesn't break anything, of course. And if it breaks, it's not necessarily the maintainers' (or worse, the users') responsibility to deal with the issue.

Or imagine having a broken upstream and someone submits a Pull Request fixing it.

Post-Merge Button Workflow
Pre-Merge Button Workflow

In contrast to most self-made solutions out there, we actually test the merged version, rather than just the fork or feature branch. Thus, we also take into account changes made upstream after the repository has been forked.

We will also re-run the tests whenever new commits are added to Pull Requests (yes, this works fine with force pushes and rebases). Also, it pretty much works with anything that is mergeable, might it be a branch, tag, fork, etc. As long as you see the green Merge Button, we can test it.

Are we there yet?

This feature is still under development. The described functionality works just fine, but we have plans for future extensions.

For instance, we would like to leave a comment whenever master is updated and give you the option to automatically rerun the tests with the new merge commit.


If you made it this far in the blog post, you probably want it for your repository, and you want it now. Good news! We started unrolling this feature.

As we are still improving it, and are not sure if we can stand the load of activating it for everyone right away, we are turning it on on a repo by repo basis.

Please note that we started unrolling for those who donated, so I was actually able to work on this. So, if you donated and want this, just let us know.

If you didn't donate, but still want to use this feature right away, our Love Campaign is still running.

Want to be notified about new articles and updates? Sign up for our newsletter, we'll send you coffee tips as well!

Questions or feedback?

Let us know what you're thinking by emailing!