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.