For as long as Hudson's had a plugin model and development community, we've provided source code and binary hosting through our Subversion repo at java.net. But what if you're a plugin developer and you don't want to use Subversion? Well, we have an alternative for your source code: host it with Hudson on GitHub.

To get this in place, send an email to dev@hudson.dev.java.net (or ask in the IRC channel) asking to get a repository created for your plugin at Github. Make sure to include the name of the plugin and your Github username (and the Github usernames of any other developers who'll be pushing to your plugin's repo). If your plugin is already in Github, include the URL for the existing repo so that we can fork it. One of the Hudson admins will create the repository (forking if appropriate) and add the user(s) to the list of users with push access to the Hudson-hosted repositories at Github. Once you hear back from them, you'll be able to push code to the new repository.

You will need to make a few changes to your plugin's POM, as compared to what works for a plugin POM in the java.net Subversion tree.

Regular readers will recognize that I've been slacking off quite a bit lately with my release announcements, my apologies. With the release of 1.368 on Sunday, which fixed a few fairly important bugs, I figured I'd dusty off my blogging fedora and give this a shot.

This release has three bug fixes in it which were causing some issues for some users, particularly those deploying Hudson inside the recently released Tomcat 7.0 (see issue 6738).

Hudson users utilizing the JDK auto-installation feature between different platforms may have been affected by issue 6880 which was also fixed in this release.

Bringing up the rear is the fix to issue 7004 which detailed a few discrepencies between the /buildWithParameters and the /build remote APIs.

If you're not affected by these issues, you may want to wait for the soon-to-be-released 1.369 which has even more juicy bug fixes in it (with a dash of enhancements) to upgrade.

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!

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.

So you've got your fancy Android cell phone and you're thinking to yourself "besides feeling smugly superior to iPhone users, what can I do with this thing?" Perhaps you should be considering using it as a phone but if that's too boring, check out the new and improved Hudson Mood widget for Android! The latest release brings support for multiple servers and fancier graphics.

If you're interested in installing the widget, search for "Hudson Mood" in the Android Market, and be sure to thank Siarhei Dudzin for creating the widget!

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.