Wednesday, March 28, 2012

Moving from Hudson to Jenkins

Last year's dispute with Oracle has caused many of the main developers of the continuous integration Hudson to fork the project into Jenkins. While the instructions for upgrading seem relatively painless, there were also several issues that we encountered when making the switch from Hudson to Jenkins:

1. You can use the Ubuntu instructions to download the latest Debian package from the Jenkins repo. You may need to be prepared to grep any of your configs to switch from 'jenkins' to 'hudson' (or to perhaps a more neutral name) that make these assumptions such as your Apache configs or build scripts. The directory in /var/lib/hudson may also need to be backed up.

2. Ubuntu also inserts new config files (i.e. /etc/default/jenkins), so you may need to update your port settings and JENKINS_HOME settings. Python in particular has problems dealing with files using symlinks so it's best not to create symbolic links that map from the old Hudson directories to the new ones.You're better off moving directory locations since the symlinks cause extra headaches that can be avoided by renaming existing directories.

3. Assuming you startup Jenkins correctly, you may go into the Manage Plugins section and be asked to upgrade your plugins. Avoid doing so until you go into the Advanced section and make sure you click on "Check now" to update the database of known plugins and Jenkins versions:

Although most Hudson/Jenkins plugins are compatible, there are issues with later forks of the Git plugin (see item #4). If you don't update your plug-in data in the Advanced section, you may end up downloading plug-ins that ony work on Hudson and not Jenkins, and may see confusing messages about needing to upgrade to Hudson v2.20 when v1.457 is the latest version since the database information is now different.

4. If you are attempting to use the Hudson git plugin, you may find this error (discussed at
FATAL: null
at hudson.model.AbstractBuild.getCulprits(
at hudson.model.AbstractBuild.getCulprits(
at hudson.model.AbstractBuild$
at hudson.model.ResourceController.execute(ResourceControl
The issue is that there are starting to be incompatibilities that arise between the Hudson and Jenkins fork of the Git plugin. When cloning/compiling plug-ins, you have to remember that there are now two separate forks that have very different implementations, one for Hudson (forked at and the other for Jenkins (forked at If you don't compile plugins, you don't have to worry about this issue but the later versions of Git plugin in particular seems to have introduced problems.

5. If you're using OpenID/SSO integration with Hudson, the OpenID plugin comes with the latest version of Jenkins but you have to compile your own version if you use Hudson. The Git plugin for Hudson already exposes the option to decide whether to create User accounts in Hudson based on author or email, but this pull request just submitted now allows for this option to be used on Jenkins.

6. The Violations plugin had problems with parsing jobs using an older version that was used on Hudson, causing certain jobs to be missing. You may have to delete the XML-based sections in your jobs and reload the configs for the jobs to be read correctly. Your best bet for tracking down these issues are in /var/log/jenkins/jenkins.log. You will also have problems viewing the Violations Summary without this pull request fix, which was reported in this ticket.

7. Starting in Jenkins v1.426, API tokens are used in lieu of passwords for OpenID/Crowd-based logins. In other words, you can no longer use pre-defined passwords and must go into the Users section and look at an individual's API token to access Hudson's API to trigger builds and retrieve information about jobs (i.e. wget needs to be changed to use the API token instead of the user's password). More detailed instructions are located at:

No comments:

Post a Comment