Last time I talked about HudsonMobi 2.0 there were some hiccups with the QR code which made me pretty irritated. Now the leading mobile app for Hudson users has regained my trust with their lastest release for iOS 4, the latest incarnation of Apple's mobile operating systems for iPhones and iPod Touches.

Since I fall into the category of subhumans who for one reason or another choose not to own an iPhone, I can't verify the awesomeness of this new HudsonMobi release. If it is anything like the 2.0 release for Android you can expect enhancements such as:

• Tighter integration with iOS 4
• Embedded artifact viewer! For archived build artifacts that are text-based, you can view them directly on your handset.
• Access to the build history and changes for a job.
• Quick and easy access to a job's last build

If you own a device with iOS 3.0 or higher you should be able to download HudsonMobi 2.0 from the appstore, if you give it a whirl, please leave a comment to let me know how awesome it is :)

Just wanted to let everybody know that I've gone ahead and added a Calendar for all the upcoming Hudson-related events.

Hopefully we'll be able to add more and more events for the rest of the year including seminars, more meetups and potentially a few drink-ups!

Worth mentioning that I've not yet tested the iCal feed so if you have troubles with it, let me know (via the comments).

Today, I’d highlight two recent improvements to the label and matrix projects.

When you have multiple slaves in your Hudson build farm, you can use labels to classify slaves by their capability/environment/architecture/etc. For example, your one slave might have “32bit” and “windows” label, while another one might have “linux”, “ubuntu”, and “64bit.” (with plugins like platform-labeler plugin, you can attach labels automatically, too.) Or if you do Selenium testing, you might add browser names as labels to indicate which slave has which browser available.

With such set up, you then specify that such and such jobs can be only run on such and such labels. For example, you might say your “test-foo” job requires the “windows” label, while your “compile-bar” job might require the “macos” label. Starting 1.372, Hudson now lets you use boolean expressions here, instead of just specifying one label as the requirement. For example, your “seleniumTest-zot” job can now say it requires “windows&&firefox” since it’s meant to run on Windows with Firefox. Or if your job requires a shell script, you might say “!windows” to indicate that it has to be run somewhere that’s not Windows.

Labels are also often used in the context of the multi-configuration project (a.k.a. matrix project.) In a multi-configuration project, you specify what to execute to build your project, then specify a number of “axes” that represents the variable and their possible values to execute a build. There are several different kinds of axes (and this is of course extensible), and one of them is the label axis.

For example, say you have a test suite that you want to run on Windows, Linux, and Solaris, to make sure it works correctly under all these environments. In such a case, you define one label axis, and tell Hudson that you have three possible values “windows”, “linux”, and “solaris.” When you build this project, Hudson will run your build three times by finding appropriate slave that carries the specified label.

In 1.373, you can now specify multiple label axes. For example, you might have a C++ project that needs to be compiled on various platforms. In such a case, you can define one label axis to be “windows”, “linux”, “solaris”, and you can define another label axis to be “32bit” and “64bit”. This will generate 3x2=6 combinations to be executed.

Sometimes the exhaustive combinations do not make sense. In such a case, you can use a filter boolean expression to eliminate some values. You can also use the same mechanism to create a sparse matrix --- that is, you tell Hudson to reduce the coverage to 33%, and Hudson will eliminate every 2 out of 3 combinations.

Finally, I’d like to thank Sandia National Laboratories for sponsoring this work, which made it possible for InfraDNA to provide this feature to the community. People often think that contributing code is the only way to give back to the project, but sponsoring features like this is another great way to do it.

September is turning into a meetup month for the Hudson community. In parallel to the meetup in Oslo and the meetup in JavaOne, Nokia and InfraDNA are hosting a meetup in Copenhagen on September 6th, Monday. Read on for the details.
<!--break-->

The current tentative plan is to do a short "state of the union / what's new" kind of presentation, then use the rest of the time for open mic Q&A, but if you have other ideas, or better yet if you want to do some talks, please let me know. I think the event will be fun.

If you plan on coming, please drop me a note, so that we can get some sense of the attendance.

• When: September 6th, 18:30
• Where: Auditorium 1, Nokia Denmark A/S, København (map)
• Food will be provided.

JavaZone is a big Java conference in Scandinavia, and Hudson is well represented there. On September 8th, Håkon Snøtun will be presenting "Top 5 plugins for Hudson and Chuck Norris." and on September 9th, I'll be presenting "Getting more out of your Hudson."

But more importantly, what is a conference without drinking!? So in that spirit, InfraDNA will be organizing a Hudson User Meetup at The Scotsman from Sep 8th 19:30 (website.) We'll get together, have some drinks, and enjoy geeky conversations.

So if you are local or visiting Oslo for JavaZone, come join us. If you plan to join us at The Scotsman, please RSVP, and watch out for my twitter updates for any last minute time/location changes.

As we near autumn up here in the Northern Hemisphere, the wind is starting to blow a bit chillier and here in the Bay Area that can only mean one thing: Oracle is suing everybody! it's time for JavaOne!

A whole lot has changed since last year, Sun Microsystems was acquired by Oracle, Kohsuke left Snoracle to found InfraDNA and Hudson has continued to power on as the single best continuous integration server on the planet.

While the tickets for Oracle OpenWorld/JavaOne are just as outrageously expensive as they were last year, we are hosting a meetup/hackathon/continuous-drinking-contest at Digg the Sunday prior. We have not yet set any kind of agenda, but some core Hudson hackers and plenty of plugin developers should be in town so it should be a great time hacking on and/or with Hudson.

RSVP Here! * When: September 19th, 1:00 p.m. * Location: Digg's Office: 1040 Mariposa St - Suite 100, San Francisco, CA 94107

View Larger Map

Note: Unlike last year, we're trying to organize this with Meetup.com, if you experience any difficulties RSVPing let us know

I'll be in Copenhagen from 9/5-9/7 and in Oslo 9/8-9/9 to present in JavaZone. I'd like to take advantage of the opportunities and have user meet-up events in those cities. Depending on the number of participants, it could be just a drink in a bar, or a talk in a meeting room.

So if you are:

1. in those cities,
2. available in the evening of 9/6, 9/8, or 9/9, and
3. willing to attend such an event,

... then please let me know.

Also, if you have an office in those cities and willing to provide a space for an event, that would be extra appreciated!

CloudBees announced the beta availability of their new Hudson-as-a-service "HaaS" today. I see this as yet another validation to Hudson, and as such, I welcome this new addition to the community and wish them well! — more companies betting on Hudson means we'll get more investment to the project, which is all goodness for Hudson users. It's been 5 months since I left Oracle to start InfraDNA, and I was initially worried about a possible negative impact on adoption, but instead Hudson has shown with no sign of slowing down (see picture on the right, from Andrew's report, which shows # of estimated active installations that participates to our usage stats survey). And InfraDNA is going well too - we've helped companies big and small to improve their Hudson usage/adoption, and our commercial value-add Hudson distribution is getting plenty of interest.

Hosted Hudson offers an interesting trade-off, compared to on-premise Hudson. On the plus side, given the current hourly pricing of public clouds like EC2 and Rackspace, you get a better pricing model, as CloudBees charge by minutes. You also get rid of machines and upfront cost, which is great for small business. On top of that, you can also expect them to gradually develop more value-adds and better integration to various other pieces, which can get really interesting.

On the down side, you have less control over the environment that runs the builds, and you do not have access back to your intranet environment (think databases that you need to talk to, for example.) Also, in the current pricing (8.5 cents/hour of EC2 vs 1 cent/minute of CB), if your build takes longer than 9 minutes, you'll save more by just using Hudson EC2 plugin.

On a related note, I think one of the sweet spots is Hudson that's well integrated with on-premise cloud solution. As you can see in the discussion with Liferay Hudson setup, with sufficient load it gets cheaper to have your own hardware, and many companies need some degree of control to the build/test environment that matches with their production environment. Plus with those on-premise virtualized environments, you can do snapshots and forks, which can be made to do very interesting things.

Finally, I think the part that everyone can agree on is that the elasticity of build environment is hugely useful to the CI environment, as I discussed in my JavaOne 2009 talk (slides.) I'm very happy to see that the foundation work we've made in Hudson for this is getting validated more and more, and I think the added elasticity will drive a lot more changes in Hudson and more broadly into the way we develop software. It is an exciting time!

On September 1st, I'll be presenting in a Sauce Labs webinar about Hudson and Sauce OnDemand. The talk will discuss how Hudson can be used with Sauce OnDemand, naturally, but it'll also cover broader Hudson/Selenium integrations.

Please register to this free event, and looking forward to seeing to you virtually.

In late 2008, the Hudson team released version 1.264 which added an anonymous reporting feature (you can opt-out in the "Manage Hudson" screen). The reporting feature has been sending information back to the Hudson team to help us understand how Hudson is used in aggregate; the info being reported includes the number of jobs configured, slave configurations, what plugins (and what versions of those plugins) are installed, and more. This data has not been available publicly until now! The raw data needed to be decrypted and scrubbed of any potentially identifying information, such as non-public plugin names or usernames in snapshot versions. We've finally scrubbed the data and are making it available!

The data is currently in monthly JSON bundles, organized by unique install key. We've filtered out reports of installations without any jobs configured, as well as any installations with only one report in a given month.

If you'd like access to the data, please send an email to dev@hudson.dev.java.net or jump onto the IRC channel and ask - we'll send you the URL and a private username/password which you'll need to access the info. We're also planning to do more analysis of the data ourselves, for now feast your eyes on this spreadsheet, which shows the total number of unique installations seen per month and the number of unique installations of each publicly available plugin per month.

(Andrew is a core committer to Hudson and the author of numerous plugins. He's the build guy at Digg, who, by the way, are hiring!)

Last Friday the Hudson team rolled out a small 1.372 with two enhancements following the critical 1.371 release on Monday. Not a whole lot to say about this release other than go get it!

Enhancements

• Persist matrix-based security settings in a consistent order (issue 7138)
• Jobs can now use boolean expression over labels to control where they run.

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.

The folks over at LMT Software just released their HudsonMobi 2.0 to the Android market. This release of HudsonMobi brings a lot of the features to Android that iPhone/iPad users of HudsonMobi have enjoyed for some time.

Features unleashed to Android users in this revision of the app are:

• Full Android user-experience with Menu and back controls
• Embedded artifact viewer! For archived build artifacts that are text-based, you can view them directly on your handset.
• Access to the build history and changes for a job.
• Quick and easy access to a job's last build\
• Restyled and updated user-experience, making HudsonMobi "feel better" on an Android device

If you want to get HudsonMobi for free from the Android Market, whip our your phone and take a picture of its QR code:

Commits often come in a burst. This seems to happen mainly for two reasons --- people sometimes forget to commit some files, and in the tranquility of waiting for your SCM to finish a commit, people sometimes realize the problems in the commit and they quickly make follow-up changes. The conventional wisdom is that the CI server should wait for the burst to finish before attempting a build. This is said to reduce the chance of having broken build, and it is also sometimes useful in reducing the average turn-around time for builds that take longer.

As such, Hudson is capable of waiting for a commit burst to be over before it triggers a new build, and this feature is called "quiet period." There are two parts in Hudson that interacts with the quiet period. One is the SCM polling behavior and the other is the queue.

The queue portion of the quiet period is straight-forward. When a build is scheduled into the queue with quiet period, the build will sit in the queue until the quiet period expires. If during this period, additional attempts are made to put the same build in the queue, the quiet period resets to its initial value. For example, if the quiet period is 5 minutes, and the build is put into the queue 9:00am and 9:03am, the actual build will only happen after 9:08am. Thus another way to think of the quiet period is that you are requiring a certain period of inactivity.

The above applies to all the mechanisms in Hudson that puts builds into the queue. This includes REST API call, CLI call, downstream triggers, and SCM pollings. So if you implement some kind of a "push" mechanism in your SCM to notify Hudson of a new commit, then you get the desired effect by just setting the quiet period in Hudson, and those push scripts don't have to do anything tricky.

It is also possible for some of those to override the quiet period configured in the project. For example, when you click "Build Now" button in your browser, your browser is making a REST API call, but with the quiet period of zero. I used to run a "push" script that looks into a commit message and overrides the quiet period by taking advantages of this feature.

The other portion of the quiet period that often matters is the SCM polling behaviour. Up until Hudson 1.346, the way Hudson defined the SCM abstraction made it impossible for SCMs to correctly report newly detected commits since the last polling. Instead, it was only possible to report if the repository is newer than the workspace. As a result, if the polling interval is set shorter than the quiet period, the build stayed in the quiet period forever. This was tracked in HUDSON-2180.

Hudson 1.346 fixed this issue, and so if you are using a newer version of Hudson and SCM plugins that take advantage of this improvement, then everything works as expected. Otherwise, avoid setting quiet period longer than the polling interval.

Hot on the heels of Hudson 1.370, which was released last Friday, the Hudson team released 1.371 which addresses a critical vulnerability in all Hudson versions prior to 1.371. The vulnerability was disclosed by InfraDNA in the following security advisory, which details the issue:

This critical vulnerability allows an attacker to use CLI commands that they are otherwise unauthorized for. CLI commands can perform various administrative operations.

It is advised that all Hudson instances be upgraded immediately to avoid data loss or other ill effects from this issue. If you're upgrading from a version earlier than 1.370, you can consult the changelog for details on the other bug fixes and enhancements covered by the upgrade of your version to 1.371.

If you run a Hudson instance, it is recommended that Hudson system admins 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.

As you may have noticed, thanks to the link on this and the other pages here at hudson-labs.org, the Hudson development community has recently introduced ci.hudson-labs.org, the official Hudson-on-Hudson instance. We're currently building Hudson proper, the Hudson core RC branch, individual builds for the various Hudson plugins and Gerrit, as well as various libraries and infrastructure jobs Hudson depends on.

We're currently running all those builds on a dedicated Linux slave, generously provided to the Hudson project by Digg, my employer. This has been great - except for the day when I'd just added all the individual plugin jobs for the first time, we haven't had real problems with capacity. But we are limited in the environments we can run our tests on as a result of only having a Linux slave. We're currently playing with a temporary Windows slave, but we'd really like to have at least one more permanent Windows slave, and a Mac slave as well, so that we can run Hudson's core integration tests on those platforms as well. Since this is Hudson we're talking about, we don't need the slave to be in any given physical location - we just need it to be running the slave process and talking to our server. If you're interested in helping us out with this, please contact me at andrew dot bayer at gmail dot com. Thanks!

(Andrew is a core committer to Hudson and the author of numerous plugins. He's the build guy at Digg, who, by the way, are hiring!)

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.

First, add the following to the <build><plugins> section:

      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-release-plugin</artifactId>
        <version>2.0</version>
        <dependencies>
          <dependency>
            <groupId>org.apache.maven.scm</groupId>
            <artifactId>maven-scm-provider-gitexe</artifactId>
            <version>1.3</version>
          </dependency>
        </dependencies>
      </plugin>

This is needed to make sure we're overriding the parent POM's SCM provider settings. Next, add the following to the <build> section:

    <extensions>
      <extension>
        <groupId>org.jvnet.wagon-svn</groupId>
        <artifactId>wagon-svn</artifactId>
        <version>1.9</version>
      </extension>
    </extensions>

This is needed because we're still going to be using wagon-svn to deploy the artifacts in the release process. Lastly, add an <scm> section, within the <project> section of the POM, like the following:

  <scm>
    <connection>scm:git:git://github.com/hudson/your-plugin-repo.git</connection>
    <developerConnection>scm:git:git@github.com:hudson/your-plugin-repo.git</developerConnection>
    <url>http://github.com/hudson/your-plugin-repo</url>
  </scm>

As with the first section, this is needed to override the default SCM settings in the parent POM. Make sure to change "your-plugin-repo" to your actual plugin repository name, of course! It'd also be a good idea to put a link to your Github repo on your plugin's wiki page at the Hudson wiki, since the default source link will go to Subversion.

Now, with these changes in place, committed and pushed to the master branch in your plugin's repository, you should be able to run "mvn release:prepare release:perform" just as you would if the plugin were hosted in Subversion, with your plugin showing up in the Update Center within a few hours. Be sure that you've configured the login information for the java.net Maven repository, as detailed here - this is still needed for plugins hosted at and released from Github, since Hudson's Maven repository still lives at java.net. If you run into any issues releasing your plugin from Github, first be sure to review the wiki page on plugin hosting, which addresses many of the issues you may encounter when running the Maven release plugin.

If you're still stumped, feel free to email the Hudson developer list or ask in the IRC channel for help.

(Andrew is a core committer to Hudson and the author of numerous plugins. He's the build guy at Digg, who, by the way, are hiring!)

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.

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.

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!