Which part of HUDSON_HOME should I put under source control?

问题

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?

回答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.

回答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.

回答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.

来源：https://stackoverflow.com/questions/1606496/which-part-of-hudson-home-should-i-put-under-source-control

标签

version-control

continuous-integration

hudson