Submitted by rtyler on Wed, 2010-07-21 08:15
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.
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.
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).
Allow multiple dependencies between same two projects, as they may trigger under
different conditions and with different parameters.
Timeline on build trend page should use server timezone instead of always GMT.
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.
Avoid pointless and harmful redirection when downloading slave.jar.
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.
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.
Add setting so job views may show only enabled or disabled jobs.
File parameters can now be downloaded from the build Parameters page.
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.
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!