Thoughts on Systems

Emil Sit

Jan 14, 2011 - 3 minute read - Technology configuration git hudson tools

Store Hudson configuration in Git

For any kind of server, it’s a good idea to keep its configuration in some sort of version control system. Hudson is a pluggable continuous integration system. Recently, I was trying to set one up and was wondering the best way to store Hudson’s configuration in version control (StackOverflow summary). The most complete answer is a post on the Hudson blog about how to keep Hudson’s configuration in Subversion; there are also plugins like a nascent SCM Sync configuration plugin. But, the former is very Subversion specific and the latter does not seem particularly mature. So, to understand how to do it in your workflow, there are two things to consider.

First, which files are relevant? Hudson puts configuration, run-time state, source code and build output all in the same sub-directory (called HUDSON_HOME). Second, relatedly, since normally you edit Hudson’s configuration through the GUI, when should you commit changes? Should it be automated (e.g., nightly at midnight) or manual (e.g., ssh into the server and manually commit)? I’ll answer those questions with an implementation in Git but you can translate the information easily to your preferred VCS.

Identify relevant files by using the following .gitignore file:

This ignores the uninteresting files and will allow git status to show you interesting new files. Note that I prefer to actually commit the binaries of plugins since I don’t want to rely on outside sources (namely, the mirror network) having the particular version of the plugin that I was using for the given configuration files. To use this if you are installing a new Hudson server, you can just

cd $HUDSON_HOME/.. # Default is /var/lib
rm -r hudson
git clone git:// hudson
# Don't forget to chown hudson hudson as appropriate for your environment

before starting Hudson for the first time. Then once it has started, run git commit to track the default config that Hudson creates.

The second question is when. The Hudson blog’s recommendation is to create a Hudson job that runs nightly at midnight to check for differences and automatically commit them. I prefer manually committing the changes on the server and then pushing it. This allows me to identify specific functional changes (using git add -p) and commit them individually. If you want to do it automatically, simply write a script or add a job that will

git commit -a -m "Automated commit of Hudson configuration"
git push

once you set up an appropriate origin.

Once you have this set up, you can even use something like Chef to automatically pull down updated configuration that you manage and test elsewhere and restart the Hudson server when necessary. Then you can re-create your Hudson server in case of failure at any time!