Continuous integration with Hudson

Open source CI server offers easy setup and configuration

Continuous integration has become common practice for teams focused on ensuring code quality throughout the software development lifecycle. In this article, Nicholas Whitehead introduces Hudson, a popular open source CI server. Learn how to set up a Hudson server in your application development environment (examples are given for Windows XP with Tomcat 6 or Ubuntu Linux with JBoss AS), get an overview of the many configuration options Hudson provides, then implement an automated build, test, and reporting process for an example project. Level: Beginner

Continuous integration (CI) is a set of practices intended to ease and stabilize the process of creating software builds. CI assists development teams with the following challenges:

  • Software build automation: With CI, you can launch the build process of a software artifact at the push of a button, on a predefined schedule, or in response to a specified event. If you want to build a software artifact from source, your build process is not bound to a specific IDE, computer, or person.
  • Continuous automated build verification: A CI system can be configured to constantly execute builds as new or modified source code is checked in. This means that while a team of software developers periodically checks in new or modified code, the CI system continuously verifies that the build is not being broken by the new code. This reduces the need for developers to check with each other on changes to interdependent components.
  • Continuous automated build testing: An extension of build verification, this process ensures that new or modified code does not cause a suite of predefined tests on the built artifacts to fail. In both build verification and testing, failures can trigger notifications to interested parties, indicating that a build or some tests have failed.
  • Post-build procedure automation: The build lifecycle of a software artifact may also require additional tasks that can be automated once build verification and testing are complete, such as generating documentation, packaging the software, and deploying the artifacts to a running environment or to a software repository. In this way artifacts can quickly be made available to users.

To implement a CI server you need, at minimum, an accessible source code repository (and the source code in it), a set of build scripts and procedures, and a suite of tests to execute against the built artifacts. Figure 1 outlines the basic structure of a CI system.

Basic structure of a CI system
Figure 1. Basic structure of a CI system

The system components come into play in the following sequence:

  1. Developers check new and modified code into the source code repository.
  2. The CI server creates a dedicated workspace for each project. When a new build is requested or scheduled, the source is retrieved from the repository into this workspace, where the build is then executed.
  3. The CI server executes the build process on the newly created or refreshed workspace.
  4. Once the build completes, the CI server can optionally invoke the defined test suite on the new artifacts. If the build fails, registered individuals can be notified by email, instant messaging, or some other method.
  5. If the build is successful, the artifacts are packaged and transmitted to a deployment target (such as an application server) and/or stored as a new versioned artifact in a software repository. This repository can be part of the CI server, or could be an external repository, such as a file server or a software distribution site like or SourceForge. The source code repository and the artifact repository can be separate, and it is actually possible to use some CI servers without any formal source control system at all.
  6. CI servers usually have some sort of console where projects can be configured and debugged, and where requests can be issued for operations such as ad hoc immediate builds, report generation, or retrieval of built artifacts.

Hudson: A continuous integration server

Continuous integration has grown in popularity over the past several years and today you have quite a few CI servers to choose from, both commercial and free. I personally had used four CI servers before a colleague recommended that I look at Hudson. I was immediately impressed by it. While I initially assumed that Hudson was not well known, a survey at the Java Power Tools site shows it as the most widely used CI server among respondents, garnering (at time of this writing) 37.8 percent of all votes.

Supported SCMs

Hudson has integrated support for Subversion right out of the box, and only a small amount of configuration is required to integrate with CVS, assuming the CVS client is installed on the Hudson host. Several other source code management (SCM) solutions are supported in the form of Hudson plugins. At time of this writing, the following SCMs are supported:

  • Accurev
  • BitKeeper
  • ClearCase
  • Git
  • Mercurial
  • Perforce
  • StartTeam
  • Team Foundation Server
  • Visual SourceSafe
  • URL SCM (a special SCM plugin that allows the use of URLs for SCM)

In this article, I will be using Subversion and the source repository at, so you won't need to install any of these plugins. (As an aside, I know someone who is working on a MKS SourceIntegrity Hudson plugin. If you are interested in that, send me an email.)

Hudson is a free and open source product hosted at It was originally written by Kohsuke Kawaguchi, a staff engineer at Sun Microsystems, who announced its release on his blog in February of 2005. Hudson has since had approximately 154 releases.

Here are some of the reasons why I like Hudson, and why I would recommend it to you, barring any unusual requirements:

  • Of all the CI products I've used, it is by far the easiest to install and configure.
  • Its Web-based user interfaces are very friendly, intuitive, and responsive, in many cases providing immediate Ajax-enabled feedback on individual configuration fields.
  • Hudson is Java-based (which is useful if you're a Java developer) but is not limited to building Java-based software.
  • Hudson is cleanly componentized and offers a well-defined and documented extensibility API in the form of Hudson plugins. This has in turn led to a large library of Hudson plugins that extend the functionality of the server; these are freely available and installable from the Hudson console.

Installing Hudson: Windows XP or Ubuntu Linux

To use Hudson, you'll need an accessible and supported source control system (see the "Supported SCMs" sidebar for a listing), source that can be built into an artifact, and a working build script. Beyond that, all you really need to install and configure a working Hudson server is an installation of Java, version 1.5 or above, and the Hudson install file, which comes in the form of a Java EE Web archive (WAR). You can start the server very simply using the following command line:

C:\hudson> java -jar hudson.war

It is probably more common, however, to deploy Hudson onto a Java servlet container that is based on the Servlet 2.4 and JSP 2.0 specs, such as GlassFish, Tomcat, JBoss, or Jetty. In the next sections, I will walk you through two Hudson installation scenarios: one using Tomcat 6 on Windows XP, and another using JBoss 4.2.3 on Ubuntu Linux. (JBoss AS 5.0 was released after this article's submission date.)

Installing Hudson: Tomcat 6 and Windows XP

I will assume that you already have version 1.5 or higher of Java installed on your Windows XP machine. Following the steps below will install Tomcat 6.0.18 using the Windows Service Installer, so that Hudson starts immediately after Windows XP boots up and will run in the background even when no user is logged in. The download file for Tomcat is apache-tomcat-6.0.18.exe, which you should execute to begin the Tomcat install.

The Tomcat installation will prompt you to select install options. Be sure to select Custom options and then Service, as shown in Figure 2, so that Tomcat will run as a service.

Tomcat installation options
Figure 2. Tomcat installation options

Next, select a directory where you want to install Tomcat, as shown in Figure 3. I highly recommend that you pick a directory with no spaces. You can thank me later.

Selecting an installation directory
Figure 3. Selecting an installation directory

Now the installer will ask you which port you want to listen on. The default is port 8080, which is probably fine; just make sure that you do not have another application using that port. If you do, Tomcat will not start properly. You will also be asked to provide a Tomcat administrator username and password. All this is shown in Figure 4.

Selecting a listening port and administrative user name and password
Figure 4. Selecting a listening port and administrative user name and password

The installer will then ask you to provide the location of the Java JRE you have installed. As you can see in Figure 5, I used Sun Java 1.6.0_07.

Selecting a Java JRE to run Tomcat
Figure 5. Selecting a Java JRE to run Tomcat

Once you click Install, the installation should run to completion and the service will start running. You can make sure that Tomcat is operating correctly by pointing your Web browser to http://localhost:8080 (substituting the appropriate name or IP address for localhost if you aren't using a Web browser running on the computer where Tomcat is installed). The Web page displayed should look something like the screenshot in Figure 6.

Verifying Tomcat installation and operation
Figure 6. Verifying Tomcat installation and operation

Now, to install Hudson, copy the hudson.war file to the webapps subdirectory of your Tomcat installation directory. If you used the same install directory shown in Figure 3, this would be C:\Tomcat6\webapps. Tomcat will hot-deploy WAR files, but the easiest thing to do now is restart Tomcat. There are two ways to do this. The first is to open a DOS shell and enter the following commands:

 C:\Tomcat6>net stop Tomcat6
    C:\Tomcat6>net start Tomcat6

The second option is to open the Services applet. This applet can be found in the Administrative Tools group in the Control Panel, which can be located by clicking the Start button on the Windows toolbar, then selecting Settings and then Control Panel. In the Services applet, locate the service named Apache Tomcat and then click the Restart button. This is illustrated in Figure 7.

The Services applet
Figure 7. The Services applet

Hudson should now be installed. You can verify this by pointing your Web browser to http://localhost:8080/hudson. The main Hudson screen is shown in Figure 8.

The Hudson start page
Figure 8. The Hudson start page

That's all there is to it! If you're comfortable with an application development environment based on Windows XP and Tomcat, you're all set. If you prefer a system running JBoss and Ubuntu Linux, read on.

Installing Hudson: JBoss 4.2.3 on Ubuntu Linux 8.04 (Hardy Heron)

To install Sun Java 1.6 on Ubuntu, open a shell and execute the following command:

 sudo apt-get install sun-java6-jdk

When issuing a sudo command, you will be prompted to enter your password.

Note that there are several ways to install JBoss; in the technique outlined here, you'll create a dedicated jboss user. This is considered a best practice, and is preferable to installing JBoss in your own home directory. The procedure outlined here has been condensed from a useful description at the Ubuntu forums.

First, you need to download the JBoss 4.2.3.GA package. Look for the file named

Next, you will need to create a user, a home directory, and a group, all named jboss. The group is a convenience not explored in this article; it will allow you to extend JBoss privileges to other users on your Ubuntu server.

Listing 1 shows the commented commands to create the jboss home directory, user, and group, and then install the JBoss server. Some commands are prefixed with sudo because they are root-privileged commands.

Listing 1. Creating the jboss account and installing the server

echo Create the jboss group
sudo groupadd jboss
echo Create the jboss user, define bash as the user's default shell and /home/jboss as the home directory
echo and make the user jboss part of the group jboss
sudo useradd -s /bin/bash -d /home/jboss -m -g jboss jboss
echo Copy the jboss-4.2.3.GA file to /home/jboss or download directly into that directory
sudo mv jboss-4.2.3.GA /home/jboss
echo Change the owner of the file to jboss
sudo chown jboss:jboss /home/jboss/jboss-4.2.3.GA
echo Log into the jboss account
sudo su jboss
echo Go to the jboss home directory
cd ~
echo Unzip the file jboss-4.2.3.GA
unzip jboss-4.2.3.GA
echo Create a symbolic link "jboss" for "jboss-4.2.3.GA".
echo This allows you to change JBoss versions with minimal changes
ln -s jboss-4.2.3.GA jboss

If the unzip command is not already installed, enter the following command (while logged in as a sudo-enabled user) to install it:

Sudo apt-get install unzip

The JBoss server is now basically installed. You could start the server using the following command:


In this example, however, you will instead install an auto startup script so that the service starts up automatically when the host starts. The JBoss download comes with three different int.d scripts, but each needs to be tweaked; you can download the script, which will enable the automatic start and stop of the server. Then run the commands shown in Listing 2.

1 2 3 4 Page 1
Page 1 of 4