Skip to main content

Make your builds always available

Posted by kohsuke on February 7, 2005 at 9:13 AM PST

When you are working on a software project, often you have other people who need to access the builds. For example, here at Sun when I work with the JAXB RI, our builds need to be handed to the quality assurance team, the TCK team, the JAX-RPC RI team, and other miscellaneous people who use the JAXB RI internally.

For many of them, this hand-off of a build is not just one time thing. It is a continuous on-going process. For example, the QA team needs a new build once we fix a bug they reported. During the lifetime of a project, this cycle happens a lot.

For this reason, it is often convenient to have a standard distribution channel of your builds, where people can always get the latest build. It is even better if there’s a permanent link to the latest build, because often other teams have their own procedure of integrating a build (such as putting that into their CVS repository), and a static URL allows automation of this process.

It is also better to have fresher builds. Our time is always more valuable than machines’ time, so it’s better to spend CPUs to start a new build now than to ask for the QA team to wait another day for tonight’s nightly build.

An added benefit of doing a constant build is that you can get notified when the workspace doesn’t build. I often forget to put back a file or two, and as a result the build breaks, and I know it’s not just me.

Hence comes the notion of “continuous build”, where a program automatically builds a new version of your build every time someone changes something in the repository. I found an tool called Damage Control that makes this easy, but unfortunately I found that it doesn’t scale to the size of the projects that I work with.

Therefore, I decided to re-implement it on my own, by using Java. I’m calling it Hudson, because in a sense this system is like a build master in my project, and Hudson sounded like just that kind of a name.

Anyway, Hudson is a web application, and the installation is as simple as dropping a war file into a web container, such as Tomcat. Everything else can be configured through the web interface.

A typical set up in Hudson is to set up a CVS changelog trigger, so that change notification e-mail from CVS will automatically start a new build. Hudson then starts a new build, assigning a unique build number, recording the build log, and archiving the results. It has an RSS feed so that people can be notified of new builds or build failures. It has a log rotation so that the history information won’t get too big.

Hudson can also be used to monitor jobs that run externally. I have many cron jobs, and I hook them all up to Hudson, Hudson records the output from a job, keeps history of past runs, and produce RSS feeds. Once I see a failure, I can go to Hudson, browse all the outputs I need to see, and find out when it started to fail. I found this to be a lot easier than going through e-mails from cron.

So, try Hudson! I hope you’ll like it.

(A part of Hudson, in particular the art work, is covered by the license of Damage Control)

Related Topics >>