Skip to content

yegor256/rultor

master
Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?
Code

Latest commit

 

Git stats

Files

Permalink
Failed to load latest commit information.
Type
Name
Latest commit message
Commit time
src
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Rultor logo

EO principles respected here DevOps By Rultor.com We recommend IntelliJ IDEA

mvn codecov PDD status codebeat badge Codacy Badge Lines of code Hits-of-Code Availability at SixNines

Rultor is a DevOps team assistant. It helps your programmers and release managers automate routine operations (merge, deploy and release), with an easy-to-use intuitive chat-bot interface. Just say @rultor hello in any of your GitHub issue and the converstaion will start.

Full documentation is at doc.rultor.com

Need help online? Try our Telegram group.

These blog posts may be helpful:

Watch these videos to understand what Rultor is for:

Default Docker image is yegor256/rultor-image

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: jcabi/jcabi-github#878.

How to Create a New Server

Rultor expects a server with installed Docker to be available. It logins there via SSH and starts Docker containers per each task. This is how you configure a server from scratch (as root at Ubuntu 20.04):

$ apt-get install -y bc
$ groupadd docker
$ adduser rultor
$ gpasswd -a rultor docker
$ echo 'rultor ALL=(ALL) NOPASSWD: ALL' >> /etc/sudoers
$ mkdir /home/rultor/.ssh
$ cat > /home/rultor/.ssh/authorized_keys
$ chown rultor:rultor -R /home/rultor/.ssh
$ chmod 600 /home/rultor/.ssh/authorized_keys

Make sure the b4.rultor.com is pointing to the server. At the moment the hosted app is working with a single server only, by this particular domain name.