CI tools testing lab: Initial setup with Jenkins

226px-jenkins_logo-svg Gerrit, Jenkins and the Jenkins Gerrit Trigger Plugin make for a relatively easy way to setup an automated code review system. Using these components, you can have Jenkins run automates tests on code while it is being reviewed in Gerrit.

But as projects grow in complexity and amount of developers, some shortcomings of of this system become apparent as the reviewed code being tested in Jenkins stops reflecting the way it will actually look when merged into the main development branch. This is an issue we came across on oVirt’s CI system.

Looking for a solution, we found Zuul – a tool developed by the OpenStack community when they faced similar issues.

This post is a first in a series of posts describing how I’ve used Docker to build a lab setup on my laptop to try out Zuul and check out its various features.

Why Docker

I wanted to have a self-contained testing lab on my own laptop so I could work on it even while I’m away from my office or off-line. There are various tools that allow for self-contained lab setup, including one written by the oVirt community, but in this case I decided to use Docker for several reasons:

  1. Docker makes containers quicker to install and run when compared to VMs – It could be down to a single “docker run” command as opposed to having to write a deceleration file prior to running anything.
  2. I’m testing high-level applications that do not require the kind of low-level OS access that VMs would provide, so containers are sufficient for my current use case.
  3. Docker has a huge library or pre-built container images, this will allow me to use ready-made containers for things I do not want to build on my own.
  4. For oVirt, we are likely to end up running Zuul on OpenShift, so creating containers would be a first step towards that.

Docker does have some drawbacks:

  1. Docker is very good at starting up lone containers. It has no notion of the full environment with multiple interconnected containers. This means that someone looking to reproduce my work would have to retrace my steps and start up multiple containers manually.
  2. Docker containers are not fully isolated from the system – for example the container’s IP is determined by what other containers are already running. What this means is that if a system is configured differently enough from mine, my setup will probably not work.

Despite these drawback, I opted to use Docker for the sake of quick progress, knowing full well that I will have to go back and make changes when the time comes to make my setup automated and reproducible.

Setting up Jenkins

The very first container I brought up was the Jenkins container. I did not want to spend too much time setting it up, so I looked around and found the very flexible Jenkins container created by the OpenShift project.

The OpenShift Jenkins container is very flexible and includes various automation scripts for doing things like installing plugins and creating users. The container can be customized using OpenShift’s “s2i” tool, but since I just want to use Docker for now, I decided to use a Dockerfile to customize it instead and create my own derived image.

Here is the Dockerfile I used:

FROM openshift/jenkins-1-centos7
COPY plugins.txt /opt/openshift/configuration/plugins.txt
RUN /usr/local/bin/plugins.sh /opt/openshift/configuration/plugins.txt

As you can see, I’m feeding in my own “plugins.txt” file, and then running the “plugins.sh” script to install the plugins I wanted. Here is the content of the “plugins.txt” file:

gearman-plugin:0.2.0
gerrit-trigger:2.22.0
shiningpanda:0.23

As one can see I’m adding to following plugins:

  1. Gearman plugin – needed by Zuul to allow it to run Jenkins jobs
  2. Gerrit trigger plugin – I’m adding this so I can also test the “old way” things are done without Zuul
  3. Shining Panda – This provides an easy way to run code inside Python virtual environments from Jenkins

After composing the files above I’ve built the container with the following command:

sudo docker build -t zuul-jenkins:latest .

Then all that was left to do we get my Jenkins container up and running by using “docker run“:

sudo docker run -d \
-e JENKINS_PASSWORD=admin \
-v /tmp/zuul-jenkins:/var/lib/jenkins:Z \
--name zuul-jenkins \
zuul-jenkins:latest

I’m passing various setting here to configure how the container will run:

  1. I’m setting an environment variable that will make the container set the administrator password for Jenkins so I can login to it.
  2. I’ve mounted my laptop’s “/tmp/zuul-jenkins” directory onto the “/var/lib/jenkins” directory in the container. That way any manual configuration I made from the Jenkins UI does not get deleted when I shut down the container. Note the “Z” flag that makes SElinux, which is enabled on my laptop, not block the container’s access to the host’s directory.

Once the container is up and running I can use “docker inspect” to find out the host and port it is running on:

sudo docker inspect \
-f $'Container running at: {{.NetworkSettings.IPAddress}} With ports: {{range $k, $v := .NetworkSettings.Ports}}{{$k}} {{end}}' \
zuul-jenkins

I can now use the specified host and port to access Jenkins from my web browser.

That’s it for this time, in this series` next instalments I will describe how I added Gerrit, and finally, Zuul.

All the code shown in the post could be found and downloaded from GitHub.

2 thoughts on “CI tools testing lab: Initial setup with Jenkins

  1. Pingback: CI tools testing lab: Adding Gerrit | Ifblog (ponderings 2.0)

  2. Pingback: CI tools testing lab: Setting up Zuul Server | Ifblog (ponderings 2.0)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s