Rultor is a merging bot by teamed.io that automates testing, merging, deploying and releasing of software on GitHub. Where typical CI systems like Travis or Jenkins run tests after commits, Rultor will validate your pull-request in a separate container before it ever even reaches the master branch. By doing this, you can guarantee your master branch will always build, rather than know it's broken after the fact.
It's incredibly simple to get started with, but the official docs can be a little confusing, so this repository provides a clean example of how to use Rultor in various situations.
First up, and very importantly: Make sure @rultor is a collaborator on your repository! This seems obvious, but is easy to miss. Collaborators can be found in your repo's settings, like so:
Next up, add a .rultor.yml file. Add the main project owner as an architect - this is a group of GitHub users who may confirm merges / deploys / releases made by Rultor. Without their permission, Rultor will not perform any actions.
If you're using Java with Maven, or any other widely used language and build system, Rultor is usually clever enough to figure out from there how to build your system. Check out the Merge section of the official basic documentation for more information.
Once added, find a pull request you'd like to have merged by Rultor. Simply write
as a new comment, and that's it: you're done!
Look at https://github.com/Winwardo/rultor-example/pull/5 to see a typical usage of Rultor.
Notice how, since we said "Closes #4" in the PR description, issue #4 was automatically closed after merge. (This is actually a feature of GitHub, not Rultor!)
In https://github.com/Winwardo/rultor-example/pull/3, see how our original commit actually broke a test.
Travis wouldn't have caught this until afterwards, but here, Rultor has stopped the faulty code ever reaching
master until it was proven fixed.
Check out http://doc.rultor.com/ for the official documentation, as well as the recommended blog posts inside.