A little background

I’ve been using Jenkins and the bits described below for a while now : from years to month, depending of which part you speak. It all works on the open source version anyone can use. I am not partial to this CI server, I just wanted to share the things that made my life easier over time. Things that will be described here and in next post are not my own only, but something we worked onto, my colleague Jonathan and I.

Introducing the magic

Jenkins is cool, but all alone it’s not worth much. What makes it great is its plugin ecosystem, which is absolutely gigantic. You can find plugins for almost everything, even the essential “green balls” one that changes the color of the balls indicating the jobs build status; and to be honest it’s one of the first plugins on my install list :) But the one I want to talk about here is the “job dsl” plugin. This awesome piece allows you to create jobs in a programmatic way. Jobs, and jobs only : not the global config : this needs to be noted because it’s often a source of confusion so better clear this now. There are several similar plugins to achieve the same thing but I settled on this one years ago and never regretted as it can support any plugin (we’ll see later) and has regular updates to support new plugins. And the way it works allows plugins to easily plug themselves to it. The documentation is good, even if it could be a bit better but it makes the bootstrap of its use fast.

With this plugin you write some groovy code. I had never written groovy before using this plugin and it did not turn out to be a problem : coming from a ruby world it has been fast to learn enough to produce some working code.

Having all the jobs as code allows to store it in git, make them go through your usual review process, be able to spot regressions. All the goodness that a “modern” workflow brings to summarize things.

Example

Here are a few basic examples to introduce the way it works :

This is some code for a simple freestyle job, with one parameter. It selects the node it will run onto via the label : the node will need the a_tool_name and a_specific_tag tags to be selected. The job will stay in queue until your jenkins has an online node that fulfills that condition. The SCM part allows to use a corporate github server. The wrapper cleans up the workspace before some work gets done And finally, we create a shell step by sourcing the content of a .sh file that lives in our jenkins config repository through the readFileFromWorkspace function. It allows us to avoid having a big multi-line string, to make this script go through shellcheck or any other validation you might imagine.

freeStyleJob("The_name_that_will_appear_in_jenkins_home") {
  description 'Desription on the job page'

  label('a_tool_name&&a_specific_tag')

  parameters {
    stringParam('branch_name', 'master', 'Branch to use')
  }

  scm {
    git {
      remote {
        name('origin')
        github('xxxx/meh', 'ssh', 'git.my.company.com')
        branch('*/master')
        credentials('my_build_user') // this is the ID of the one created in the credentials
      }
    }
  }

  wrappers {
    preBuildCleanup()
  }

  steps {
    shell(readFileFromWorkspace('scripts/an_awesome_build_script.sh'))
  }
}

I hope this makes a nice introduction to this little serie of posts. Next one will be one about using a (JSON) data source to create your jobs.