Recently our fearless leader, Kohsuke Kawaguchi, was invited by the nice folks over at Digg to give a tech talk about continuous integration and automated testing. The Digg engineering team is full of believers in continuous integration, including our very own Andrew Bayer (abayer). Being big users of the Sauce Labs service to drive their vast Selenium test suite, the house was packed with Selenium hackers/users and Hudson users, the stage was set for Kohsuke to give a great presentation.

You can find slides of the presentation here

Last Friday the Hudson team released release 1.363 which is yet another mixed bag of enhancements and bug fixes. Along with the usual bunch of fixes, this release includes a number of localization updates courtesy of a team of Hudson community volunteers participating in the Hudson Internationalization project.

It is also worth noting that this post is being published on Tuesday, contrary to the schedule that I operated on with Continuous Blog, I will no longer be posting release updates on Monday morning. Traditionally Hudson is released Friday afternoon (PST), meaning any potential regressions are reported early on Monday morning after our European users start to upgrade. Publishing this release announcement on Tuesday gives me more time to test out the release so I can report with greater confidence in the reliability of the update. (Note: This may change in the future as we push for easier RC testing capabilities within Hudson)

If you're a regular reader of the Hudson Labs blog, you may also notice that this change log looks eerily similar to the 1.362 announcement from last week. Turns out I had mistakenly taken the upcoming changes from 1.363 and reported them as fixes in 1.362; I've since updated the post regarding 1.362's change log.

Bug Fixes

• Fix queue handling to close locking gap between removing job from queue and starting build, to prevent unintended concurrent builds (refactor of change first made in 1.360). (report)
• Allow multiple dependencies between same two projects, as they may trigger under different conditions and with different parameters. (issue 5708)
• Timeline on build trend page should use server timezone instead of always GMT. (issue 6692)
• Don't mask the cause of the checkout related exception.
• "who am I?" page should be visible to everyone.
• Reinstall a JDK when a different version is selected. (issue 5551)

Enhancements

• Avoid pointless and harmful redirection when downloading slave.jar. (issue 5752)
• Cache downloaded JDKs.
• Integrated community-contributed translations (Germany, Greek, Spanish, Finnish, Hungarian, Italian, Japanese, French, Russian, Slovenian, Dutch, Traditional Chinese, Swedish, Ukrainian, and Portuguese.)
• Upgraded bundled Ant to version 1.8.1. (issue 6562)

The 1.362 release of Hudson has a few bug-fixes and a few minor enhancements, all together a good stabilization release. Not too much interesting to discuss so straight on to the changelog!

Bugs

• Restored optional container-based authentication for CLI. (issue 6587)
• Fix javascript error when a plugin uses an empty dropdownList, resulting in LOADING overlay being left up. (issue 6542)

Enhancements

• Add setting so job views may show only enabled or disabled jobs. (issue 6673)
• File parameters can now be downloaded from the build Parameters page. (issue 6719)
• Added an ability to point to different update sites.
• Added a new extension point to plug in custom utility to kill processes.
• Added a proactive error diagnostics to look for a broken reverse proxy setup. (report)

People often configure Hudson to start a new build whenever a change is made to the repository. In fact, this is often considered central to the practice of continuous integration.

There are two ways to achieve this. One is the "pull" model, where Hudson periodically reaches out to a Subversion repository to see if there is any changes. The other is the "push" model, where you make the Subversion repository reach out to Hudson.

Both approaches have trade-offs. The pull model is easier to configure, since you can do this entirely from Hudson. But this comes at the expense of increased load to the Subversion server. Even though the overhead of Subversion polling is relatively low, as you add more projects to Hudson and increase the polling frequency, the overhead may get non-trivial (imagine the number of Hudson pollings that the poor java.net Subversion server gets, for example.) A more serious downside, in my opinion, is that this increases the delay from your commit to a build. For example, if your build just takes 5 mins, then even if you poll every minute, you pay on average 30 seconds delay before a build starts — a 10% overhead!