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
         


        

Answer 1

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 2

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.

Answer 3

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.