CI tools testing lab: Adding Gerrit

indexIn this post I’m going to describe how I quickly brought up Gerrit using Docker in a lab setup, and integrated it with Jenkins.

This post is the second 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.

Please see the previous post for an explanation of my goals, choice of tools and work done previously.

Since I’m focused on testing Zuul, I did not want to spend too much time setting up Gerrit. Instead I looked for a ready made container image that I could quickly bring up.

Bringing up Gerrit

After looking for a while, I found a Gerrit container image made by the Fabric8 project, that was flexible enough for my needs.

I needed just one Docker command to start up the container, but it required specifying a few non-trivial parameters, so a wrote a little script to run it:

#!/bin/bash -x
DIRS=(/tmp/zuul-gerrit/site /tmp/zuul-gerrit/ssh-keys)
for dir in "${DIRS[@]}"; do
  [[ -d "$dir" ]] && continue
  sudo install -o 1000 -g 1000 -d "$dir"
sudo docker run -d \
  -v /tmp/zuul-gerrit/site:/home/gerrit/site:Z \
  -v /tmp/zuul-gerrit/ssh-keys:/home/gerrit/ssh-keys:Z \
  --name zuul-gerrit \
sudo docker inspect \
  -f $'Container running at: {{.NetworkSettings.IPAddress}} With ports: {{range $k, $v := .NetworkSettings.Ports}}{{$k}} {{end}}' \

The container image allows for two volumes to be mounted into it, so that Gerrit’s state and settings could be stored outside of the container and persist when it shuts down. In lines 3-6 I create the directories to be mounted as these volumes, and set the right permissions to allow the Gerrit process in the container to write to them. In line 9 and 10 I mount those directories onto the container while instructing SElinux to not allow access to these volumes to any other container.

In line 8 I pass a variable to the container to switch off user authentication so I can easily have access to all account on this Gerrit server.

The command in lines 13-15 prints out the container’s IP address and exposed ports once it is brought up.

The complete script above can be seen on GitHub.

Integrating with Jenkins

Just to ensure my Jenkins and Gerrit setup matches what I have in production currently, I’ve configured the Gerrit Trigger Plugin in the Jenkins server I’ve described in part 1. To do this I roughly follow the procedure described here.

To allow Jenkins to connect to Gerrit, I’ve created an SSH key pair for it in the Jenkins container. In order to do that I needed to fix a small issue in the Jenkins container where the “jenkins” user in “/etc/passwd” does not match the user actually running the processes in the container. I made a quick fix with the following command:

sudo docker exec -u 0 -it zuul-jenkins sed -i -re \
  's/^(jenkins:x):[0-9]+:[0-9]+:(.*)$/\1:1001:0:\2/' \

This fix will not persist across container invocations, but generally I do not need it to at this point. To permanently fix the issue I would probably need to add the command above to the Jenkins Dockerfile. One thing to note here is the use of the ‘-u 0‘ option to ‘docker exec‘ to force the command to run as root in the container rather then the container`s built-in UID (1001).

I could now create an SSH key pair for Jenkins with the following command:

sudo docker exec -it zuul-jenkins ssh-keygen

Running the command and accepting the default options it offers, would create a key pair in “/var/lib/jenkins/.ssh/id_rsa“. It is located on the  persistent volume we mounted into the container, so we can rest assured that key will remain even if the container is shut down.

To see the public part of the key we just generated we can simply run this command:

sudo docker exec -it zuul-jenkins cat /var/lib/jenkins/.ssh/

We can now go to the Gerrit web UI, create a “jenkins” user  (Do not forget to set the user name or SSH access would be blocked!) and upload the public key.

I also added the “jenkins” user to the “Non-Interactive Users” group in Gerrit and them assigned permissions to it as described here, with the small difference of setting all the permissions on “All-Projects” rather then on a specific project.

Next, I configured the Gerrit Trigger in the Jenkins UI by going to “Jenkins” -> “Manage Jenkins” -> “Add New Server” and setting the following properties:

  • Hostname: (The IP of our Gerrit container)
  • Frontend URL:
  • SSH Port: 29418
  • Username: jenkins
  • SSH Keyfile: /var/lib/jenkins/.ssh/id_rsa


We can now create projects in Gerrit and jobs in Jenkins that are triggered when patches are submitted to these projects.

That’s it for this time. In the next instalments of this series I’m finally going to start deploying Zuul as an alternative triggering mechanism to Gerrit Trigger.


4 thoughts on “CI tools testing lab: Adding Gerrit

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

  2. Pingback: CI tools testing lab: Adding Zuul Merger | Ifblog (ponderings 2.0)

  3. Pingback: CI tools testing lab: Integrating Jenkins and adding Zuul UI | Ifblog (ponderings 2.0)

  4. Pingback: CO tools testing lab: Making it do useful work | Ifblog (ponderings 2.0)

Leave a Reply

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

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

Google photo

You are commenting using your Google 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 )

Connecting to %s