This is a mobile version, full one is here.
24 July 2014
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:
.rultor.ymlYAML configuration file from the root directory of your repository.
Gets automated build execution command from it, for example
Checks out your repository into a temporary directory on one of its servers.
Merges pull request into
Starts a new Docker container and runs
bundle testin it.
If everything is fine, pushes modified
masterbranch 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.