Which part of HUDSON_HOME should I put under source control?

Question

I'd like to manage Hudson's configuration files with subversion for backup. The Hudson Wiki lists the directory structure of $HUDSON_HOME like so:

HUDSON_HOME
 +- config.xml     (hudson root configuration)
 +- *.xml          (other site-wide configuration files)
 +- fingerprints   (stores fingerprint records)
 +- plugins        (stores plugins)
 +- jobs
     +- [JOBNAME]      (sub directory for each job)
         +- config.xml     (job configuration file)
         +- workspace      (working directory for the version control system)
         +- latest         (symbolic link to the last successful build)
         +- builds
             +- [BUILD_ID]     (for each build)
                 +- build.xml      (build result summary)
                 +- log            (log file)
                 +- changelog.xml  (change log)

Obviously jobs/[JOBNAME]/builds shouldn't go into source control but config.xml is a good candidate. Plugins and fingerprints are less obvious.

How do you manage your Hudson configurations?

Answer 1

I do use an SCM for managing my Hudson configuration. I keep the top-level config.xml and the config.xml for each job. I've got a little script that I use to fetch the configs from Hudson and commit/add/delete them as necessary (along with some other bells and whistles that makes managing the configuration easier).

Re Rob Hruska's points, for my particular setup:

• configurations do change often (notifications, especially)
• (see above re a script to make the updates)
• I diff things all the time. We have more than one admin who can update the configuration, and these diffs are useful

All that said, every situation is different. The management I do for the configs didn't (and doesn't) come for free. A cron job that zips everything up nightly is definitely cheaper and may be sufficient, too.

Answer 2

A SCM probably isn't the best tool for backing up Hudson's workspace - it would be like using an Subversion to store preferences for a game or the contents of database tables for a web application. Along with that, it doesn't seem necessary for the following reasons:

• The configuration files don't (or shouldn't) change frequently (like code), so nightly backups are sufficient.
• When you make changes via the GUI, something's going to have to go out to the system and do an svn commit. Since this would probably be a manual step, it leaves room for human error.
• You'll probably never need to diff your configuration changes, and for the off-chance that you might, you can just extract and look at the appropriate backups (see below).

All in all, it would just seem a bit unwieldy to use Subversion for this task. For backing up, I would recommend just setting up a cron job that does a tar cvzf $HUDSON_HOME. You could optionally omit the build directories, but that seems a bit unnecessary if you've got enough disk space.

Edit: Regarding the differences between this and oeuftete's answer, my answer is simply from my experiences with how I use Hudson. His/her answer definitely provides a different perspective, which is nice. I definitely agree with it in that every situation is different, and may require different means to satisfy an end.

Answer 3

I found a good cookbook for setting up SVN backup for Hudson: http://javaadventure.blogspot.com/2010/07/keeping-hudson-configuration-and-data.html

I've adapted it for my own needs, but the things you should backup from Hudson home directory are:

• config.xml for each job (jobs/*/config.xml)
• everything in the users directory
• a listing of what plugins you have installed

The link also has some extra SVN goodness, like removing non-existent job configs, etc.