In an earlier post I wrote about how to get started with Eclipse, Mercurial and Google Code. In a follow-up to that; I’ll describe how I set up local continuous integration for the same project using Hudson. If you’re into agile development methodologies you’re probably well aware of the importance of such an exercise. Even if you do not practice these arcane arts and just lack central build server; such an set-up can be useful.

My idea was to write a script that will put together all the pieces required and start the Hudson server with as little user input as possible. This way anyone (including myself) with access to the source code, can set up building with a minimum of effort.

I also wanted the finished set-up to do the following:

The setup script I contemplated using ANT but decided on Bash. Consequently the script will only work on *nix hosts or Windows with MSYS or Cygwin. ANT is still used to start the build and do the post processing.

The script itself is placed in the releng folder of the Mercurial repository described in the earlier post. In addition to this I needed templates for creating the Hudson job and promotion configuration, the ANT script (build.xml) and the build.properties for PDE build.

The first thing setup.sh will do is to check if there is a HUDSON_HOME environment variable. If that is the case the existing location for Hudson will be used instead of creating a new one. This is useful when it’s desirable to have only one instance of Hudson running while working on multiple projects set up in a similar manner.

It is assumed that the script is executed from the folder where it is placed and that this folder is the releng folder inside the Mercurial repository in the Eclipse workspace. The reason for this is that the location is used to determine which Mercurial repository to use. It is also required for finding the Google Code credentials used when uploading built artifacts.

The script will download and prepare all required components. For instance if the Hudson WAR file is not present the script will download it, the same for all plug-ins required. It will also make sure that Hudson has the required configurations for the job. Note that these will be updated each time the script is executed.

I also needed an Eclipse instance for the PDE build. Since it is hard to correctly detect which installation to use I set the variable ECLIPSE_HOME inside my .profile. When running the script using external tools from within Eclipse, I replace this variable with the path to the running instance.

Using the base Eclipse location the script will also try to figure out the path to the launcher and the PDE build scripts. This way there should be no need to change any properties between Eclipse versions.

Usage As soon as I start working on the project I just start Hudson using setup.sh. Builds will be performed continuously and after each I will have an Equinoix p2 repository that I can install from when wanting to test the full package. Typically I have one plain Eclipse installation where I’ve added the location of the repository (http://localhost:8080/job/Buildmonitor/ws/repo/). Since the version number of the feature is incremented on each build I only need to use Help > Check for Updates to get the new version.

Summary Future extensions could be to run JUnit tests (don’t have any for this project yet), update Eclipse Marketplace information and maybe introduce different promotion states.

If you find this interesting you may want to look at the source code. It should be straightforward to tweak for your own purposes.