Rultor.com, a Merging Bot

You get a GitHub pull request. You review it. It looks correct—it’s time to merge it into master. You post a comment in it, asking @rultor to test and merge. Rultor starts a new Docker container, merges the pull request into master, runs all tests and, if everything looks clean—merges, pushes, and closes the request.

Then, you ask @rultor to deploy the current version to production environment. It checks out your repository, starts a new Docker container, executes your deployment scripts and reports to you right there in the GitHub issue.

Why not Jenkins or Travis?

There are many tools on the market, which automate continuous integration and continuous delivery (let’s call them DevOps). For example, downloadable open source Jenkins and hosted Travis both perform these tasks. So, why do we need one more?

Well, there are three very important features that we need for our projects, but we can’t find all of them in any of the DevOps tools currently available on the market:

Merging. We make master branch read-only in our projects, as this article recommends. All changes into master we pass through a script that validates them and merges.
Docker. Every build should work in its own Docker container, in order to simplify configuration, isolate resources and make errors easily reproducible.
Tell vs. Trigger. We need to communicate with DevOps tool through commands, right from our issue tracking system (GitHub issues, in most projects). All existing DevOps systems trigger builds on certain conditions. We need our developers to be able to talk to the tool, through human-like commands in the tickets they are working with.

A combination of these three features is what differs Rultor from all other existing systems.

How Rultor Merges

Once Rultor finds a merge command in one of your GitHub pull requests, it does exactly this:

Reads the .rultor.yml YAML configuration file from the root directory of your repository.
Gets automated build execution command from it, for example bundle test.
Checks out your repository into a temporary directory on one of its servers.
Merges pull request into master branch.
Starts a new Docker container and runs bundle test in it.
If everything is fine, pushes modified master branch to GitHub.
Reports back to you, in the GitHub pull request.

You can see it in action, for example, in this pull request: jcabi/jcabi-github#878.