Posts Tagged ‘Hudson’

Doing Continuous Integration Testing? Check Out Our CI API

November 4th, 2010 by Santiago Suarez Ordoñez

Testing is a key ingredient in CI. And so in the constant effort to make our service insanely flexible and easy to use, we’ve released a brand new API that will help Continuous Integration servers such as Hudson, Bamboo, and TeamCity send Sauce OnDemand some interesting information about each test they run.

This includes the pass/fail final status of the test, the build number in which it was run, and even your own custom data.

Since some of this new job info is known only when the test finishes (e.g. whether the job passed or not), we’ve created not only one but two alternative methods for the info to be sent – the REST API and Selenium’s standard setContext command. Both are documented in our docs, and anyone interested can use them right now.

Once the info makes it to our end, it will be appropriately displayed with each job, helping our users find and group their jobs with less effort. (Notice that some of the work needed to display this in a cool way is still in our TODO – but the data is there). You can see some example jobs [1] with this data set or just create your own!

In the near future, we’ll be working with the authors of the Hudson and Bamboo plugins to add support for these CI APIs.

If you’re interested in hearing more, trying early versions of these plugins, or would like to see a plugin for another CI system, feel free to ping us here!

[1] https://saucelabs.com/jobs/4baf3ad0cd8b686ef554135c4addf621,
https://saucelabs.com/jobs/0d925d14c23888b8561215360b70a78d

Share

Kohsuke Kawaguchi Demos Cross Browser Testing with Hudson + Sauce OnDemand

September 3rd, 2010 by Ashley Wilson

As part of our featured webinar series, Kohsuke Kawaguchi, creator of Hudson and founder of InfraDNA, recently led an interactive demonstration on using Hudson with Selenium and Sauce OnDemand. In case you missed the live presentation on September 1, check out the recorded video to learn more about:

1. Setting up the Hudson plugin for Sauce OnDemand
2. How using Hudson for CI will drastically speed up your testing process
3. Tips for integrating Hudson with Selenium Grid
4. Tips for integrating Hudson with Sauce OnDemand

Share

#SFSE Meetup Videos: Hudson with Selenium + Sauce OnDemand

July 20th, 2010 by Ashley Wilson

At our last #SFSE meetup at StumbleUpon, Kohsuke Kawaguchi, the creator of Hudson, gave a fantastic presentation on Hudson and the integrations with Selenium. He also unveiled a new Hudson plugin for Sauce OnDemand, documented here in an earlier blog post.

Hudson is an easy-to-use, open-source Continuous Integration (CI) server that supports distributed builds and multiple extensions, including those for Selenium. The first video below gives background on Hudson, the reasons for its development, and the features included. The second two videos walk you through using the Hudson Sauce OnDemand plugin, which makes the Hudson & Selenium integrations quicker and easier to utilize.

If you’d like to see this presentation in its entirety, check out our Sauce Labs YouTube channel. Thanks again to our friends at StumbleUpon for providing a great space for us to use for the event. To hear these talks in person, join our Selenium meetup group. We generally host meetups once a month around the Bay Area, featuring different Selenium topics and speakers, so join in the conversation!

Hudson Background:

Sauce OnDemand Plugin:

Share

Library for Hudson Sauce OnDemand PlugIn

July 19th, 2010 by Ashley Wilson

By Kohsuke Kawaguchi

As promised in my earlier post, today I’ll talk about the library that does the heavy-lifting for the Hudson Sauce OnDemand plugin. This library is called Sauce REST API, and defines a Java API to access Sauce OnDemand REST API. It’s built by Maven, and deployed to java.net Maven2 repository.

The library is capable of basic CRUD (create, read, update, and delete) operations over SSH tunnels. To use this library, you create a SauceTunnelFactory instance, then use the CRUD methods defined on it.

For example, to set up a tunnel and tear it down, do as follows:

SauceTunnelFactory tunnelFactory = new SauceTunnelFactory();

// create a new tunnel for the intranet host foo.corp.infradna.com
// wait until the tunnel is ready
SauceTunnel t = tunnelFactory.create("foo.corp.infradna.com");
t.waitUntilRunning(30000);
assertTrue(t.isRunning());

// reverse port forwarding so that foo.corp.infradna.com:80
// will come to localhost:80
t.connect(80,"localhost",80);

// do something with the tunnel
...

// destroy the tunnel (and all port forwardings that go with it)
t.destroy();

You can also list the current active tunnels, if you’d like to.
This lists all the tunnels that belong to your account, not just the ones
created by the current process:

for (SauceTunnel t : tunnelFactory.list()) {
    System.out.println(t.getCreationTime()+" "+t.isRunning());
}

In these examples, you see I didn’t pass in the user name and API key explicitly. This is because the library reads the credential from a property file at ~/.sauce-ondemand, which should look like this:

username=kohsuke
key=12345678-abcd-cdef-1234-1234567890ab

This encourages all the applications that use this library to share the same credential source, which is more convenient for users. Of course, if your application wants to control the credential in its own way, you can use a different overloaded version of the SauceTunnelFactory constructor to pass it in explicitly.

The Maven-generated documentation and javadoc are also available.

Kohsuke Kawaguchi, the creator of Hudson, wrote the majority of Hudson’s core single-handedly. He is a founder of InfraDNA, which provides products, services, and support for Hudson.

Share

Kohsuke Kawaguchi Announces New Hudson PlugIn for Sauce OnDemand

July 6th, 2010 by Ashley Wilson

By Kohsuke Kawaguchi

There has always been some overlap between Hudson users and Selenium users. As a result, the support for Selenium in Hudson, such as the Selenium Grid plugin, has generally been good. But while this Selenium Grid support, for example, does make it easier for you to run cross-platform, cross-browser tests, setting up the right OS/browser combinations, especially in the environment that doesn’t use virtualization, can be tedious.

This is where Sauce OnDemand comes into play. Sauce OnDemand solves this problem by offering browsers running in the cloud. But these browsers need to be able to talk to the web server being tested, which is most likely inside a firewall. Although Sauce OnDemand offers a SSH port forwarding option to handle this, setting up and and then tearing them down (or keeping them going all the time) is time consuming, especially when you are running your tests on a CI server that spans across multiple computers.

I wrote the new “Sauce OnDemand” plugin to fix this problem. With this plugin, Hudson will set up and tear down tunnels automatically for you.

Usage

Once you install a plugin from Hudson’s update center, go to the system configuration and specify your Sauce OnDemand credential:

Then, for each job that uses Sauce OnDemand, tell Hudson to set up SSH tunnels before the build. Hudson will tear them down at the end of the build.

Your projects don’t need anything in their build scripts to do this, which saves a lot of time if you have multiple projects/modules that use Sauce OnDemand. This also avoids the complexity of maintaining a persistent connection, which has its own complications. SSH tunnels on Sauce OnDemand starts very quickly, normally about 10 seconds, so the impact of this to the total build time is minimal.

Host name auto-allocation

Once you start using Sauce OnDemand extensively in Hudson, you’ll notice one problem. Normally you hard-code the host name that browsers connect to (which points to the cloud side of the tunnel and then forwards it back into your intranet to your webapp), but if you do that, you won’t be able to run such tests concurrently on Hudson, since the tunnel setting is global to your account.

In other words, imagine hard-coding your test to send HTTP requests to “example.org”, and you have two active branches of that project in development now. If the builds of those branches happen to run at the same time, their tunnel setup collides!

In the Hudson plugin, I added a mechanism to let Hudson auto-generate a unique host name when it sets up a tunnel. To do this, specify “AUTO” where you normally specify the domain name (“example.org” in the above example). Hudson will generate a random host name and make that host name available as the environment variable named SAUCE_ONDEMAND_HOST.

Your test should then look up this value and pass it to Selenium when you connect to it.

Under the hood

The implementation of this is done in two parts. First I wrote a library that performs SSH tunnel setup and tear down, and then I wrote a Hudson plug-in around it. The former is reusable on its own, and would be useful if you want to take the same idea and apply it elsewhere other than Hudson. My next post will talk more about this library, so stay tuned!

Kohsuke Kawaguchi, the creator of Hudson, wrote the majority of Hudson’s core single-handedly. He is a founder of InfraDNA, which provides products, services, and support for Hudson.

Share