Jenkins builds of GitLab branches stopped working due to security patch

There have been some security patches to Jenkins recently, which have stopped some plugins from working – in our case, the Gitlab Merge Request Builder Plugin.

Parameters that used to get passed in as part of a trigger to build a branch stopped being passed through.

Errors in the Jenkins build console output looked like this – you can see that ${gitlabSourceBranch} is not being replaced properly with the branch name:

git config remote.refs/remotes/origin/${gitlabSourceBranch}.url # timeout=10

And the log file had lots of entries like this:

May 17, 2016 9:25:33 AM hudson.model.ParametersAction filter
WARNING: Skipped parameter `gitlabSourceBranch` as it is undefined on `knowmalaria-merge`. Set `-Dhudson.model.ParametersAction.keepUndefinedParameters`=true to allow undefined parameters to be injected as environment variables or `-Dhudson.model.ParametersAction.safeParameters=[comma-separated list]` to whitelist specific parameter names, even though it represents a security breach

To get the branches building again, we had to update the parameters that the Jenkins server is started with.

In /etc/init.d/jenkins, set up a list of the parameters that the build will need :

# allow parameters to be passed in to gitlab builds

and pass those parameters to the process at startup:

# --user in daemon doesn't prepare environment variables like HOME, USER, LOGNAME or USERNAME,
# so we let su do so for us now

Then restart your Jenkins server:

sudo service jenkins restart

You may have a different list of parameters that need to be passed to the build – check the ‘parameters’ page for one of your previous builds.

See more description of the original security flaw here:

Using Jenkins to run remote deployment scripts over SSH

We use Jenkins to deploy code to multiple servers, so that we can manage builds and deployments from the same (even better if you’re using the Jenkins IRC plugin).

The deployment is done by a parameterized build job, where the parameter is the version of the project that we want to deploy. The job will run remote commands over ssh on servers that you’ve defined in the Jenkins configuration. Those commands will pull down a version of our code, unpack it, and run the rest of the install steps.


First you’ll need to install the Publish over SSH Plugin, which will allow files to be transferred to your servers and remote commands to be run.

Set up the SSH key for remote access of your target servers, in the Manage Jenkins page:

and setup the definitions for each of the servers that you want to deploy to:

Then in the configuration for the new deployment job you’ve set up, you’ll use the “Send files or execute commands over SSH before the build starts” settings in the “Build Environment” section to remotely execute a script to carry out the install steps on each remote server:

Notice that the build parameter “$version” is available to the Exec command that gets remotely executed – other Jenkins environment variables will also be available (e.g. $BUILD_NUMBER, $JOB_NAME etc).

Use the “Add Server” button to add more target servers, with the same Exec command.

Now you can deploy your project (or run any other remote scripts) by running the build job and specifying a version number.


Building github branches with Jenkins

We usually work on several parallel branches of a repo on github, and we wanted to be able to build and test any branch on demand.

So we set up a parameterised job in Jenkins that will take the name of a branch and run the build process.

As for all github builds, you need to have installed the git plugin first ( and set up your github globals in the Jenkins settings:




Then set up a parameterized build job with the repo as the GitHub project and with “branch” as the parameter to be specified:

and in the Source Code Management section, add the parameter to the “Branches to build”:

Don’t specify any build triggers – you’ll probably just want to run this on-demand against specific branches, rather than every time there’s a push to the repo (which is what happens by default).

Now you can build any branch just by giving the branch name as the required parameter when the job is started.




CruiseControl is dead, long live Hudson

We’ve been using Cruise Control as our continuous integration system for ages, but problems with Subversion checkouts finally drove us to try Hudson as an alternative.

It’s fantastic – configurable from the UI, it archives build logs as well as artifacts, it’s got console output in the browser, and so on. Why didn’t we switch earlier?!

Anyhow, only slight modification need to make the lava lamps work with Hudson.

The lamps are controlled by an IP power switch, with the 4 outlets turned on or off by hitting a url with some GET parameters (ok, it’s not RESTful, but come on..). A cron job fires invokes the script every minute with the “check” command to parse the RSS feed of latest build results from Hudson, and light the lights accordingly.

Cron also calls the “off” function after 5pm, to save the lamps from burning out overnight.

The script is something like this :

check() {
        # check Hudson on localhost and switch on lamps accordingly
        FAILCOUNT=`wget -O - -o wget.log http://localhost:8080/rssLatest | grep FAIL | wc -l`
        PASSCOUNT=`wget -O - -o wget.log http://localhost:8080/rssLatest | grep SUCCESS | wc -l`
        if [ $FAILCOUNT != 0 ]; then
                echo  `date` " : BUILD HAS FAILED"
        elif [ $PASSCOUNT != 0 ]; then
                echo  `date` " : BUILD IS OK"
pass() {
        # switch outlet 1 on and 3 off
        wget http://ip-switch.local/Set.cmd?CMD=SetPower+P60=1+P62=0 -q --delete-after
fail() {
        # switch outlet 3 on and 1 off
        wget http://ip-switch.local/Set.cmd?CMD=SetPower+P60=0+P62=1 -q --delete-after
off() {
        # switch them all off and go home
        wget http://ip-switch.local/Set.cmd?CMD=SetPower+P60=0+P62=0 -q --delete-after