Yo Dawg, I heard you like Jenkins

These past few days I’ve been busy re-factoring my JenkinsAPI project. One of my goals was to greatly increase test-coverage. It’s somewhat ironic that a project that was all about testing had very few tests.

Most of the tests in this package try to do something to a Jenkins server and then check for consistency:

For example you can start with a new, clear Jenkins. If you add a new Jenkins job and then read-back the list of jobs you might expect to see one more job in that list. This sort of test is easy to get working on a PC, you simply start up Jenkins before running the tests. But what of the situation where these tests are run on a remote CI server, for example on Jenkins. Any tests that connect back to the server and mess about with that server’s configuration are bound not to work reliably.

I heard you like Jenkins

In order to get this kind of test working in a Jenkins environment the solution I found was to launch another Jenkins.

I wrote a threaded Jenkins launcher which starts a background sub-process and then monitors the Stdout and Stderr streams for error conditions. It returns, keeping the sub-process alive once the Jenkins server has fully started. We keep a reference to the subprocess so that when all the tests are complete I can shut the whole thing down.