Hudson/Jenkins Subversion Authentication

Recently I've been setting up Hudson to do continuous integration on some java projects in subversion and I've run into a few issues with Hudson's SVN authentication mechanism.

In short, when you add a project into Hudson and set the SVN credentials via Hudson's "enter credentials" link it stores the credentials internally and not in SVN's .subversion directory, this leads to the following problems:


  1. Any user who can create a job in Hudson can access Hudson's stored SVN credentials.
  2. Hudson only stores one set of credentials per hostname (e.g. http://repo.com/svn/test-repo and http://repo.com/svn/other-repo share the same credentials).
  3. If you try running the maven changes reporting plugin during a build it will hang trying to do a "svn log" command because it's waiting for a username/password at the console (i.e. not using Hudson's stored credentials).

I've managed to work around the above issues, but it does require a few steps and making sure everyone understands how you use Hudson.

The first issue is a limitation of Hudson and there isn't really a remedy, you have to work around it. The issue comes up since one of the build actions when creating a job is writing a shell script, which essentially gives you access to the filesystem underlying Hudson and thus every other repository checked out by Hudson. Also, Hudson stores SCM credentials in base 64 encoded text, so it's trivial to write a shell script to retrieve them with a build.

Unfortunately, there's nothing you can do about it; you just need to understand that any user you allow to create a build can access everything in Hudson: all the project's source, SCM credentials, build artifacts, etc... This leaves you with a couple of choices; either don't allow developers to create new jobs, which may be a viable solution for some, if it's not, the other option is to run multiple instances of Hudson, one for each project (or group of projects); which allows per project access control but means you have more servers to administer.

The second problem (Hudson only storing one set of credentials per hostname) is an annoyance since it means that the stored credentials can be overridden when a developer adds a project and uses their own credentials, thus breaking every job they don't have access to.

My solution is fairly simple:

  1. Create a user for Hudson and give it access to the projects you will be building in Hudson
  2. Make sure that all your developers know and follow the correct procedure (add the Hudson user to their project and don't ever change the credentials in Hudson).
  3. Store the user in both Hudson and in the servers .subversion directory (you can do this by checking out a repository somewhere on the system as the user running Hudson) 

Not a perfect solution, but it's done the job fairly well for us.