I've released the Hudson Selenium plugin, which instantly lets you deploy Selenium Grid on top of your existing Hudson cluster. By using this plugin, you can start using Selenium Grid without installing it on individual machines in the cluster manually. This is the latest addition to the family of plugins that let you reuse you Hudson cluster infrastructure for additional purposes.

Once you install this plugin from the update center, Hudson master will become the Selenium Grid hub, the center of the Selenium Grid system. Similarly, each slave that you have in your cluster will now run Selenium RCs. The whole process happens completely automatically, without any additional configuration.

To connect to this grid from your Selenium tests, create aDefaultSelenium instance by specifying the host name of your Hudson master, like this:

new DefaultSelenium("hudson.mydomain", 4444, "*firefox", "http://site.that.iam.testing/");

By default, Selenium Grid randomly chooses a Selenium RC to carry out the execution, but this behavior makes it difficult to reliably start a platform dependent browser (like IE and Safari), that needs to be run on specific computers. As such, it's convenient to be able to specify the slave that runs the browser. To do this, Hudson Selenium Grid plugin extends the stock Selenium Grid by extending the browser identifier. Specifically, you can specify "label1&label2&...:browser" to tell Selenium Grid to start the specified browser on a slave that has all the given labels. For example, if your Windows slaves have the "windows" label, the browser identifier of "windows:*iexplore" would cause a Selenium RC on some Windows slave to start the IE.

We are increasingly seeing tools like Hadoop and Selenium, which requires a cluster of computers to operate. Given the rise of multi-core systems, cloud computing, and other general shift for increased parallelism, I expect this trend to continue. Now, the problem of those tools is that it's harder to set them up and keep them going. One of the things I want to do with Hudson is to enable their deployments on the Hudson cluster. I think this is a convincing value proposition, given that Hudson byitself is pretty easy to install and maintain (even on a cluster), and that it already has an update center built-in.

I intend to talk more about this in my JavaOne session, so please drop by!