rultor: a chat bot in your GitHub issues that merges and releases for you

The trigger is a chat command in a GitHub issue

rultor is a DevOps team assistant that helps programmers and release managers automate routine operations, namely merge, deploy, and release, through what the README calls an easy-to-use intuitive chat-bot interface. The mechanism is short enough to state in one line. You say `@rultor hello` in any of your GitHub issues and the conversation starts. Everything the tool does is driven from that conversation, and the README points to a merge command reference and to a schema file, `rultor_schema.json`, for the `.rultor.yml` configuration. The audience is a team that already works from GitHub issues and pull requests and wants the routine operations triggered by a sentence rather than by a person with credentials. That last point is the actual product. The point is not automation for its own sake, it is removing the need for one human to hold the merge and deploy permissions.

Pre-flight builds are what makes the merge safe

The What Problems Does Rultor Solve section explains the reasoning in a way that is worth reading closely. Rultor performs pre-flight builds. Instead of merging into master and then seeing if your changes broke the build, it checks out the master branch, applies your changes to it, then runs everything it was set up to run. If, and only if, everything goes well, it merges the changes into master. The README states that this programmatically prevents the master from being broken by developers, and that not having to worry about breaking the build for everyone else has a positive impact on the way developers write code, increasing their productivity and mitigating their fear of making mistakes. The second point is the one that matters most in practice. A merge button that is safe changes how people submit changes.

Every build runs in its own container

The first benefit the README lists is isolation of the deployment script in its own virtual environment by using Docker containers, which substantially reduces the amount of external state that could affect your build and makes errors more easily reproduced. The second benefit is log retention. Because of the way rultor integrates with modern issue trackers, all the logs are stored and published to the ticket on which rultor was mentioned, making key information easily accessible to all developers. The third benefit is the interface itself, since rultor provides an integrated and humanized interface to DevOps tools, as a human-readable sentence suffices to trigger a merge or a release. The default Docker image is `yegor256/rultor-image`, and the repository topics mention docker, docker-container, chatbot, continuous-delivery, and deployment, which matches what the README describes.

The merge sequence is seven steps and it ends in a push

Once rultor finds a merge command in one of your GitHub pull requests, the README lists exactly what happens. It reads the `.rultor.yml` YAML configuration file from the root directory of your repository. It gets the automated build execution command from it, for example `bundle test`. It checks out your repository into a temporary directory on one of its servers. It merges the pull request into the `master` branch. It starts a new Docker container and runs the build execution command. If everything is fine, it pushes the modified `master` branch to GitHub. And it reports back to you, in the GitHub pull request. You can see it in action in a linked pull request on the jcabi/jcabi-github project. Notice that step five is where the isolation matters, because the merged result is what gets built, not a merge that happened first and got tested afterwards.

A YAML file decides what your project runs

The `.rultor.yml` file in the repository root is the configuration point for every project that uses the tool, and the README links a schema file, `rultor_schema.json`, that describes it. The repository itself has a `.rultor.yml` at the root alongside the schema, plus a `Procfile`, an `app.json`, and a `deploy.sh`, which is the shape of a hosted service rather than a library. The `deploy.sh` and `Procfile` combination suggests a Heroku-style deployment, and the app.json file is the manifest format that platform expects. The point for a reader is that adopting rultor does not mean adding a dependency to your build. It means writing a small YAML file that says which command to run, and trusting that command to be a real test.

What the project looks like from the inside

The repository is a Java project built with Maven, with a `pom.xml` at the root, `src/` for the sources, and `system.properties` for the JVM configuration. The build badge is a Maven workflow, and the project tracks coverage with codecov, code quality with codebeat, and static analysis with Codacy. There is a PDD status badge from 0pdd, which is the tool that scans for puzzles in the source, and a Hits-of-Code badge for the comment and documentation density, both of which are unusual signals that the maintainer treats documentation and code structure as measurable properties. The repository also carries a `LICENSES/` directory and a `REUSE.toml` file, which is the mechanism for the software bill of materials that the licensing requirements imply, and the licence itself is a custom one that GitHub cannot classify, with the text in `LICENSE.txt`.

Where rultor is the wrong tool

There are three boundaries, and they are structural rather than fixable. The first is that the tool assumes a merge or release can be automated end to end. If your process requires a human to approve a release, or a sign-off from a second team, then the chat command either does not fit or you end up bypassing it, and then you have two paths. The second is the Docker requirement, since every build runs in a container and a project that cannot be containerised cannot use the pre-flight build that is the whole safety argument. The third is the GitHub coupling, because the interface is a comment in a GitHub issue and the logs are published back to the ticket, so a team on another issue tracker, or one that needs the logs elsewhere, is outside the design. The README also points at blog posts arguing that deployment scripts are dead, which is the tool's thesis stated plainly, and it is a thesis with a specific opinion about where build logic belongs.

Editorial conclusion

rultor fits a team with a GitHub-hosted project, a build command that is trustworthy, and a workflow where merges and releases should be triggered by someone other than the person holding the deploy credentials. It is the wrong choice if your release process needs manual sign-off, if you do not run Docker, or if your issue tracker is not GitHub, since the whole interface is a comment in a GitHub issue. Before you adopt it, write a `.rultor.yml` with a build command that fails loudly, and read the documentation on doc.rultor.com, because the README states the tool is a hosted service with a schema file for that configuration and a default Docker image rather than a library you embed.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. yegor256/rultor on GitHub