In my last post I showed how to create a simple Redmine plugin from scratch. Being good developers we also created some test cases, but wouldn’t it be nice to have them run automatically against a range of Redmine versions?

Enter Travis CI

Just in case you’ve been living somewhere on a very remote island for the last years - Travis CI is an awesome continuous integration testing service that is tightly integrated with GitHub and totally free for open source projects.

So if you host your Redmine plugin on GitHub anyway it’s a no-brainer to use Travis CI. For me, Travis CI is actually the reason why I mirror all of my Redmine plugins (and also other stuff) on GitHub, even if I host the primary repositories elsewhere.

Set up Travis CI for your Redmine plugin

In order to make use of Travis CI you need to create a file called .travis.yml at the top level of your Repo which tells Travis what to do, i.e. which Ruby versions you want to run on, what other software packages your tests depend on and any other setup steps that need to be performed.

For running Redmine plugin tests we need to prepare a few things that are common for each plugin:

• get a copy of Redmine
• install the plugin inside
• set up a test database
• execute Redmine’s redmine:plugins:test rake task.

The set of possible variables that we might (and should) change to test our code in different environments are:

• version of the plugin that is to be tested (i.e. master branch, any released and still supported versions)
• Ruby version
• Redmine version
• Database (PostgreSQL, MySQL)

The first two items are easily covered by using a .travis.yml like this:

language: ruby
rvm:
  - 2.0
  - 2.2
  - jruby-9.0.1.0

branches:
  only:
    - master

This would run tests only against the master branch of our plugin, but with three different Ruby versions.

Travis CI doesn’t know anything about Redmine and it’s versions, but it has a generic way to extend the build matrix further via environment variables:

env:
  - REDMINE_VER=2.6-stable
  - REDMINE_VER=3.1-stable
  - REDMINE_VER=master

Now the Travis CI build matrix has three dimensions - Travis will run tests for each unique combination of Ruby version, branch and environment. You might add any number of combinations of environment variables to expand this even further, i.e. to pick different databases like Redmine does.

But who’s going to make use of the environment variables? I have a shell script for this which I originally borrowed from the Redmine backlogs plugin. Given a set of environment variables, this will do the right thing for any Redmine plugin, so I simply copy that over for every new plugin I build, along with a test database configuration.

Here’s the remainder of .travis.yml:

addons:
  postgresql: "9.4"

install: "echo skip bundle install"

before_script:
  - psql -c 'create database travis_ci_test;' -U postgres

script:
  - export TESTSPACE=`pwd`/testspace
  - export NAME_OF_PLUGIN=redmine_percent_done
  - export PATH_TO_PLUGIN=`pwd`
  - export PATH_TO_REDMINE=$TESTSPACE/redmine
  - mkdir $TESTSPACE
  - cp test/support/* $TESTSPACE/
  - bash -x ./travis.sh

First we instruct Travis to set up a recent version of PostgreSQL. Next we override the install step (which by default would run bundle install for Ruby projects), because we do not want this at this stage. The before_script simply creates the test database, and the main script part creates some more environment variables and finally invokes the test script.

The only thing that I have to change from plugin to plugin is the NAME_OF_PLUGIN environment variable, everything else stays the same unless I want to run tests against different Redmine versions and / or databases.

Git tag step-five shows the addition of the travis config and supporting files to the Redmine Issue Done Ratio Plugin.