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.
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.