The developer for the Hudson extension for Google Chrome, Sebastian Sanitz, emailed the users@ list today to inform the community of an update to his fantastic extension.

Sebastian's extension monitors ci.hudson-labs.org by default, but the URL and polling interval are both trivial to change. When any of the builds in the configured URL fail, you'll see a red "Fail" indicator, otherwise green "Ok".

If you're interested in contributing to the plugin, good news! It's open source! You can find it on GitHub.

Over the past year Hudson has grown tremendously, both within the Java community and outside of it. Partially thanks to Titus Brown's PyCon 2010 Atlanta coverage of continuous integration for Python (which we've covered before), Hudson has made great strides within the Python community as well.

In my experience, the majority of Python developers are not using Hudson to build anything, unless they have C extensions, but rather to test their packages, which presents its own set of specific requirements for jobs. Jobs for testing Python code need to be able to reliaby reproduce an environment with the same set of dependencies from one run to the next in order to provide consistent testing. Unlike their Java counterparts, Python developers cannot rely on a powerful system like Maven2 for enumerating build/test targets or defining their project's dependencies in their jobs; fortunately, w e can have something close: virtualenv and pip.

Virtualenv does exactly what you might expect it to, it creates a "virtual environment" with custom site-packages directory, and modified python executable. Using virtualenv you can create a staged environment to use for running unit and integration tests. Adding pip alongside that and you have a fantastic Python package manager/installer to use with the virtual environment.

Below, I've outlined the steps required to use virtualenv and pip to automatically manage a custom environment for your Python jobs.

Squee-D had some nice things to say in the #hudson IRC channel yesterday that I thought I would share:

Just to sing some praise again, make sure you all know how appreciated it is, we absolutely love hudson, and appreciate everyone who develops and maintains it.

Positive feedback (and negative really) is always appreciated; have you thanked your plugin maintainer today?

The Hudson team has released Hudson 1.365 which contains a critical security fix! A security advisory released yesterday by InfraDNA goes on to explain the hole with more detail:

This vulnerability allows an attacker to read arbitrary files in the server file system whose path names are known, by sending malicious HTTP GET requests. While such access is still subject to the normal access control enforced by the operating system, Hudson can still leak "secrets" possessed by Hudson

The vulnerability inside of Hudson affects Hudson instances running inside the embedded Winstone container, instances behind Glasshfish or Jetty (for example) are not subject to this vulnerability. Instances running behind a reverse proxy such as mod_proxy or Nginx.

Hudson system administrators should subscribe to either the security advisories RSS feed or the advisories@ mailing list

You can go grab the latest .war file straight from our OSL mirror or if you're using a native package, use your package manager to upgrade.

It's been quite a while since I posted a Hudson links-roundup post, so without further ado, here goes nothing

• Max tells us about using Hudson with Symbian's CodeScanner tool.
• Running slaves on Mac OS X? Mirko has some handy launchctl foo for keeping his JNLP slaves online
• Scott threw up a great configuration sample for running Hudson with an Nginx reverse proxy with SSL
• Mark walks us through using Xvfb to run headless cucumber/selenium tests with Hudson
• Our friends behind Build Doctor wrote an interesting build radiator that works seamlessly with Hudson.

Hudson, like all web applications, is not immune from vulnerabilities that could open up attack vectors for malicious use. What puts Hudson in a league of its own compared to others is its ability to execute arbitrary commands on slave machines, or in the case of the EC2 plugin, execute arbitrary commands "in the cloud." In light of all this, Hudson is quite secure and offers a variety of mechanisms to reduce the potential for exploits.

Despite Hudson's security track record, you've managed to find a vulnerability in Hudson, and decide to don your white hat and inform the Hudson team. First off, let me commend you on your brilliant decision to report the vulnerability, you are truly a leader among men.

Generally immediate public disclosure of vulnerabilities is frowned upon as it doesn't give us much time to react, investigate and patch the hole. For this reason there is the "SECURITY" project in Hudson's JIRA. The SECURITY project is a more locked down section of JIRA than the other projects and allows you to submit issues and have them reviewed by the Hudson core developers who can assess the vulnerability.

Last week, friend-of-Hudson Leandro Nunes sent the following message to the users mailing list regarding his upcoming talk on continuous integration and Hudson:

Next month I will present a talk about Hudson in the 11th International Free Software Forum (FISL 11), held in Porto Alegre Brazil (detailed time and date of the talk are not yet scheduled so).

FISL 11 is one of the biggest free software events in Latin America and will quite literally attract thousands of free software users, hackers, and enthusiasts. It will be held from the 21st to the 24th of July in Porto Alegre, if you're in Central or South America, you should definitely try to attend.

Leandro will have Hudson stickers on hand to give out and will surely do a fantastic job presenting Hudson to all those future Hudson users, I hope you can make it!

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

Way back in March, I asked you all: Want some Hudson stickers?

Turns out, a lot of you do! Thanks to a huge amuont of help by my future wife , the first shipment of Hudson stickers went into the mail last week. This first shipment was only to United States addresses! If you live outside of the U.S., or if you requested more than 50-ish stickers, I've not yet been able to send you stickers. I expect to start sending out international shipments later this week and early next week.

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)