Jenkins configuration as code

Configuring Jenkins is not as easy as one might imagine or want. There are some 1500 plugins available. Selecting the proper plugins and then configuring them is a daunting task.

Jenkins configuration as code doesn't solve the selection problem. But it does solve the problem of having a repeatable setup of Jenkins. The setup is version controlled and thus traceable.

Here is an example where I use this this tool chain:

• Jenkins
• Docker
• Java
• Maven
• Git

A working example is available at GitHub.

Two Jenkins jobs - one Jenkinsfile

I have a situation where I want two jobs in Jenkins to have the same definition. They will run a set of tests against two different environments.

I want to name the jobs so it is obvious which environment they target. My naming schema looks like this: *-dev

The jobs will therefore be named as:

• integration-tests-dev
• integration-tests-sys

Which artifacts do you want when you build a system?

A Continuous Integration, CI, server builds a system every time a change has been detected in the version control system. This is a very common practice and something good. We are able to catch many silly mistakes early. The question is, what should the CI server build? Which artifact should the build produce?

Set working directory for your Jenkins continuous build server

How do you set the working directory for your Jenkins (formerly known as Hudson) continuous build server to something else than System.getProperty("user.home")+"/.hudson"?

Failing Maven builds in Hudson

Maven has a default behaviour that it fails a build if a test fails. Hudson and Jenkins turns this default behaviour up side down. Maven builds that fails are marked as unstable instead of failed. This behaviour may be surprising to anybody setting up a Maven build.

Getting started with Continuous Integration

A quick Continuous Integration introduction example.