Jenkins configuration for Mongrel2

This repository holds the minimal set of files to get an instance of Jenkins working with several Mongrel 2 jobs.

Installation

Prerequisites

To run this, you need:

• A working Java environment,

• wget to install the plugins,

• all the dependencies needed to build Mongrel 2 if you expect to build it locally (that’s a good idea to start with that simple configuration — we’ll see how to build on remote slaves later).

Instructions

If the prerequisites above are met, then the following should work:

1. Make sure Jenkins is stopped if already present or installed on your machine

2. Backup your previous Hudson/Jenkins configuration somewhere if needed:

   $ [ -d ~/.jenkins ] && mv ~/.jenkins ~/.jenkins_backup
   $ [ -d ~/.hudson ] && mv ~/.hudson ~/.hudson_backup

   In short, you must make sure that neither ~/.hudson nor ~/.jenkins is present.

3. Clone this repo, download Jenkins (if needed unless you prefer using your distro package manager) and install the plugins:

   $ cd <any directory where to hold the repository>
   $ git clone git://github.com/chickenkiller/jenkins_mongrel2.git
   $ ln -s $PWD/jenkins_mongrel2 $HOME/.jenkins
   $ cd $HOME/.jenkins
   $ wget http://mirrors.jenkins-ci.org/war/latest/jenkins.war
   $ ./install_plugins.sh

4. (Optional) For code coverage, download the gcovr script and make it executable (it needs Python 2.x to run)

Warning

It’s important to install the plugins before starting Jenkins or it may mess up the jobs configuration files that expect those to be present.

Running

There are several ways to execute Jenkins:

• If installed with your distribution package manager, you could use the provided service/startup scripts

• If you’re brave and master Java servlet containers (Tomcat, Glassfish et. al), you can deploy jenkins.war in your container

• An embedded lightweight servlet container (Winstone) is included in jenkins.war, so the easiest way for a quick start is:

  $ java -jar $HOME/.jenkins/jenkins.war

Wait for startup, and visit the URL of your instance. In the Winstone case, the default is http://localhost:8080/.

(Optional) If you want the code coverage job to work, go to your slave configuration page (Manage Jenkins → Manage Nodes → <your slave> → Configure) and add the environment variable GCOVR that should point to the location of the gcovr executable script.

For more information, visit the Jenkins Wiki.

Jobs

A job in Jenkins is a set of configuration. Each job is isolated in its own folder, and may be run on any number of slaves. More or less, we can approximate a job purpose to a build configuration; for example, there could be a build in debug mode, a build in release mode, another one with coverage informations, unit testing etc…​ They are also associated with a repository, can poll it for changes, can get a remote build action trigger, and can trigger other jobs when successful (or not).

The huge number of functionalities you can integrate into a job directly depends on the number of plugins installed, because the plugins give new powers to jobs. But we’ll try to concentrate on the more important ones, because a tank is not needed for our slim mongrel2.

Here are the current existing jobs configured for mongrel2:

mongrel2_master

Compile the source code from the master branch in default mode

mongrel2_develop

Compile the source code from the develop branch in default mode

mongrel2_develop_clang

Compile the source code from the develop branch with the LLVM Clang static analyser. Also publish the HTML report automatically.

mongrel2_develop_coverage

Compile the source code from the develop branch with a make coverage like command line, then use the gcovr script to generate an XML report following Cobertura format to get the results nicely integrated. Uses the Cobertura plugin.

A few default reports are available for now:

Warnings

this plugin scans for warnings/errors from the GCC toolchain. Very useful to get the trend. Goal: 0 warning, of course! Now you have no excuse not to help.

Sloccount

Show the lines of codes and in which languages. Useful to make sure the codebase does not grow too much (or too slowly, depends ;))

Open Tasks

scans the source files for TODO, FIXME and XXX entries to report them nicely. Very flexible, can be extended to scan for anything you want.

What then?

First, have a look at the web interface. It’s so easy to understand there should not be much more to explain.

I’ll try to give more details on the functionalities of the installed plugins, and procedures to set up remote slaves and other more complex setups, but later.

Have fun.

TODO

• Done, but to be reviewed Integrate code coverage (hints here)