views:

208

answers:

4

I'm just starting with hudson and I'd like to build my projects like my handmade solution did before:

  1. Retrieve the current svn revision number rev.
  2. Build all projects (each with individual result) with the revision number rev.
  3. Start again with step 1 regardless if there were any changes in the meantime (to detect nondeterministic errors that don't occur on every test run).

How can I configure this with hudson?

+2  A: 

Hudson doesn't really have good support for making a single SVN check-out and then using it for several different jobs.

You could try this:

  • Set up a job that just does the check-out to a known directory. Check the post-build-actions > build other projects box and add all the build jobs.
  • Set up each of the build jobs to copy over the latest check-out from wherever the first job placed it. Have these set up to build periodically so they will continue to build even when there are no check-ins happening.
  • Possibly use the Locks and Latches plugin to set up locks between the check-out job and the build jobs so you don't end up with two jobs trying to copy/modify the files simultaneously.

It sounds messy and potentially fraught with problems, but it might work.

Alternately, if you want to just chain all these projects together, you could set up a single job that does the checkout and has a build step for each project. Then you could just check the Build Periodically trigger to have it run as often as you want (or at least as often as Hudson can get through the tasks).

sjohnston
A: 

you can always add a shell script as a build step.

use a parameterized build, declare the revision as parameter, use the parameter in your shell script (skipping Hudson SCM management entirely)

http://wiki.hudson-ci.org/display/HUDSON/Parameterized+Build

seanizer
+2  A: 

Just to extend the sjohnston post. Instead of checking the code out to a known location, you can use the Clone Workspace SCM Plugin. Now you can reference the checkout from the first job.

In addition you can just pass around the revision number and pass it as a parameter to your build jobs. The build jobs can than retrieve the right version of code by using the revision number.

Peter Schuetze
Very nice! I didn't know about that plugin.
sjohnston
It is a pretty new plugin, based on a pretty old Ticket. :)
Peter Schuetze
+1  A: 

My take on the problem:

Use the SVN post-commit hook to trigger a preliminary job which a) checks out the code; b) gets the SVN revision (e.g. via SVNVERSION.EXE); and c) uses the Parameterized Trigger plugin to trigger the "real" build job at the specific SVN revision ID.

This way you separate the SCM connection from the actual building, so that you can be very specific about building every revision.

William Leara