There are three main operations you can perform with Rultor: merge, deploy and release. Every call to Rultor is posted in a Github issue as a comment (yes, any Github issue, in any Github project!)
Commands must start with
@rultor followed by command text.
For example, in a pull request that is ready to be merged you post a new comment saying, literally:
@rultor please check and merge this pull request
It is important to start a command with
merge somewhere in the text. All the rest is ignored.
You can achieve exactly the same thing by just posting:
BTW, by default, only Github project collaborators can talk to Rultor, although it is configurable.
It is a very good practice, to run your automated build
after merging a pull request into the
branch and right before pushing changes. When your pull request
is ready, ask Rultor to merge it. Rultor will checkout your
master branch, merge changes into it, run the automated build,
and push the new version of
master to your repo.
"Master Branch Must Be Read-Only"
article explains why it is important to use this mechanism and
master against accidental failures.
Don't forget to create
in the root directory of your repository and configure the build
automation script there. For example:
merge: script: mvn clean install
If you don't configure it, Rultor will try to guess your
build automation tool and call it accordingly. If you
pom.xml in your root directory —
it is Maven; if you have
Gemfile — it is Bundler, etc.
We strongly recommend that you configure your script in
Deployment is when you place a packaged artifact into your production (or test) environment in order to make it available for end-users (or testers). Different systems deploy themselves differently — Rultor makes it possible to automate any possible scenario.
All you need to do is define your deployment scenario as
a bash script and configure it in
For example, this is how we deploy Rultor
itself (see our
deploy: env: MAVEN_OPTS: "-XX:MaxPermSize=256m -Xmx1g" script: - "sudo bundle" - "mvn clean deploy -Prultor --settings ../settings.xml" - "mvn clean site-deploy -Psite -Prempl --settings ../settings.xml"
First, we install all Ruby gems required for Jekyll (this is how this website is built). Then, we deploy the system to CloudBees. Then, we deploy the site to Github Pages.
The Release command automates this for you. The command does require one mandatory argument, though. You should call it like this:
@rultor release, tag=`1.7`
Then, in your script you get
$tag environment variable,
which will be set to
1.7. Your script should change
the version of the product to 1.7 and build it.
This is how we do it in jcabi
rultor.yml. For example:
release: script: | mvn versions:set "-DnewVersion=$tag" git commit -am "$tag" mvn clean deploy -Pqulice -Psonatype -Pjcabi mvn clean site-deploy -Psite -Prempl --settings ../settings.xml
We change the version of the product to the one provided in
$tag, then commit the changes, build and deploy to Sonatype. Next,
we build the project site and deploy it to Github Pages.
All the rest is done by Rultor. Basically, this is what will be done:
- Check out your repository
- Run the script configured in
- Tag the latest commit as
- Push the new tag to the repository
Of course, if any of these steps fails, the entire command fails and you get a full log in the Github issue.