Public | Automated Build

Last pushed: 18 days ago
Short Description
Default Docker image for builds
Full Description

<img src="" width="64px" height="64px"/>

Full documentation is at

These blog posts may be helpful:
Every Build in Its Own Docker Container,
Master Branch Must Be Read-Only,
Rultor + Travis, and
Rultor, a Merging Bot.

Default Docker image is yegor256/rultor

What Is Rultor?

TBD... product statement

What Problems Does Rultor Solve?

Automated deployment scripts have been around for some time. Rultor attempts to
tackle the problems those scripts do not.

The first benefit of Rultor is that it gives you isolation of your deployment
script in its own virtual environment by using Docker containers. This
substantially reduces the amount of external state that could affect your build
and makes errors more easily reproducible.

Additionally, 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 vital information easily accessible to all developers.

Rultor performs pre-flight builds. Instead of merging into master and then
seeing if your changes broke the build or not, Rultor checks out the master
branch, apply your changes to it, then runs everything it was set up to run.
If, and only if, everything goes well, Rultor merges the changes into master.
This programmatically prevents the master from being broken by developers. Not
having to worry about breaking the build for everyone else has a very positive
impact in the way developers write code, increasing their productivity and
mitigating their fear of making mistakes.

Lastly, Rultor provides an integrated and humanized interface to DevOps tools,
as a human-readable sentence suffices to trigger a merge or a release.

How Rultor Works?

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

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

You can see it in action, for example, in this pull request:

What Is Rultor SLA?

TBD... quality requirements

How to Contribute

Fork repository, make changes, send us a pull request. We will review
your changes and apply them to the master branch shortly, provided
they don't violate our quality standards. To avoid frustration, before
sending us your pull request please run full Maven build:

$ mvn clean install -Pqulice -PdockerITs

To avoid build errors use maven 3.3.x and have a Docker environment properly
loaded into the shell from which you run the build.
If your environment does not have the ability to run a working Docker client
and daemon, you can run the build without the Docker based integration tests

$ mvn clean install -Pqulice

Docker server

The server where Docker works must be Ubuntu 16.04.

Install Docker.

Create rultor user and add it to docker group.

Add rultor to sudoers.

apt-get update -y
apt-get install -y mailx
apt-get install -y gnupg2
apt-get install -y bc

Got questions?

If you have questions or general suggestions, don't hesitate to submit
a new Github issue.

Continuous Integration

We're using all possible continuous integration systems, mostly
for fun :) Here is our selection criteria.<br/><br/><br/><br/>

Less interesting and/or stable stuff:<br/><br/><br/><br/><br/><br/><br/>

Docker Pull Command
Source Repository

Comments (0)