Continuous Deployment on the new Digg

In my capacity as Build Guy at Digg, I've written up a blog post on our new continuous deployment/code review/pre-tested commit workflow. We're using a combination of Hudson, Git and Gerrit, Selenium and more to make sure that every change going to Digg's new site has been thoroughly tested.

Read the whole post, with all the juicy details over on Digg's Technology Blog!

Hudson with Selenium and Sauce On-Demand Videos

A few weeks ago, Kohsuke stopped by the San Francisco Selenium Meetup hosted by Sauce Labs to talk about all things Selenium and Hudson related (with a bit of Sauce in there too).

The good folks over at Sauce Labs have gotten around to posting some of the videos taken with Kohsuke.

Instead of embed the videos, I wanted to directly link to the post and make sure that you all went over to check out Sauce Labs, they're up to some interesting things over there.

Hudson 1.363 Released!

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)


  • 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)

Hudson 1.362 Released

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!


  • 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)


  • 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)

Subversion repository change notification: push vs pull

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 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!