DevOps Zone is brought to you in partnership with:

Gerard Davison is a Senior Principal Software Engineer working at Oracle in the UK on SOAP and REST tooling. Currently he is contributing in the area of WADL generation and client generation in the Jersey project and is maintaining the Abbot swing automation project. He also maintain a small holding of Hudson nodes run all those tests. He graduated from the University of Reading with a degree in Human Cybernetic and can't help looking for feedback loops. Gerard is a DZone MVB and is not an employee of DZone and has posted 32 posts at DZone. You can read more from them at their website. View Full User Profile

Off-loading Your Test Execution Using Hudson/Jenkins: Part1

  • submit to reddit

One of the annoyances if you have a load of tests for a particular project is that running them can tie up your machine for a while. There are also sometimes consistency issues when running on different machines with different window managers and operating system versions. One thing we do is for every main hudson job we create a copy just to run the tests for a particular developer. It solves the "it runs on my machine" dilemma and frees up the developer to get on with other work. In our part of the organization running the tests on another machine is a mandatory step before merging to main.

This example uses subversion; but it most likely work equally well with any other source control system with a similar interface. It also assumes that all the developers are working on branches, you are doing this right?.

First of all you take a copy of you original job, in my case I am running test for the abbot project so I am starting with "abbot_SF", and create a copy of this job with a suitable postfix. In our case the job is called "abbot_SF_TestTrans". You need to first disable any normal build triggers so this job only gets used when there is a manual action. We keep the results separate as it makes the normal build results much easier to interpret.

So to this new job add a new Parameter "BRANCH" of type string and update the repository URL to contain this parameter, so in my case$BRANCH. You will also notice that I have the used the description setting plugin to capture the branch name automatically. (You could also just put the $BRANCH parameter in the description field and leave the RegEx blank). After you have finished you have something like this, ignore the red ink as that appears to be a local configuration issue.

Now if you click build on the job you get a nice interface where you can ask Hudson to build a particular branch, leaving the developer to get on with the next job while the build machine does it's business.

Speaking of that, it looks like I have some bugs to fix...

P.S. You might also want to tick the "Execute Concurrent Builds if necessary" flag so that if you have more than one developer you can make proper use of your farm.

Published at DZone with permission of Gerard Davison, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Fahmeed Nawaz replied on Tue, 2012/06/12 - 10:38am

There's a typo in the paragraph 'Making a connection' at the beginning of the document.
create many mongo intances -> create many mongo in_s_tances

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.