Archive for the ‘hudson’ Category

My Upcoming Presentations

June 3rd, 2010

I will be presenting Hudson (with a focus on its Selenium support/integration) at the upcoming San Francisco Selenium Meetup event on Jun 22nd in San Francisco. There are several Selenium-related plugins in Hudson, but running Selenium tests on Hudson involves some initial setup cost. I’d discuss those, plus general-purpose features in Hudson that really work well with Selenium.

In the week after that, from 30th to July 3rd, I’ll be in Israel, thanks to JFrog. This is my first visit to Israel, so I’m really excited. If there are any Hudson users there who’d like to meet up, please let me know, as I’m always interested in seeing different deployments of Hudson and learn from those. Or if you are interested in having me do a short on-site work, there won’t be any travel cost, so this would be a good opportunity ;-)

Further down the road, I’ll be speaking in JavaOne 2010. Historically we have a good number of Hudson committers/users in JavaOne, so we’ve been doing some get-together. I hope we can do it again, so please stay tuned as the details of the conference develops over the summer.

hudson , ,

Auto-discovering Hudson in the network

May 14th, 2010

When you are writing an application that interacts with Hudson, it is often convenient to be able to auto-discover Hudson deployments on the same network. This improves the overall user experience.

There are several ways to do this — one way to do this, which is supported for the longest time, since 1.282, is via the UDP broadcast to port 33848. You send an empty UDP datagram to port 33848, and all the Hudson instances on the same network will reply an XML fragment UDP packet to you, that looks like this:

  <version>1.354</version><!-- version of the Hudson -->
  <url>http://server/hudson/</url><!-- the top page of the Hudson -->
  <slave-port>12345</slave-port><!-- TCP port number for slaves and CLIs to connect to -->
  ... more elements may appear here ...

Starting 1.335, Hudson started using IP multicast socket to listen to this broadcast, so you can discover them by sending a broadcast packet to instead of — depending on how the network is configured, this can also reach beyond the same subnet.

Starting the upcoming 1.359, you can also discover Hudson via DNS multi-cast at “_hudson._tcp.local”. This also defines a convention that enables wide-area discovery of Hudson — such as “” for the Hudson deployed for The same version, url, and slave-port parameters are available as the key/value pairs associated with this DNS record, so you can find the actual URL of Hudson instances that way.

As we the engineers use more and more server applications for software development, more seamless integrations between them get more important, and I think the auto-discovery is a very important part of this.


Interview with DZone

April 29th, 2010

I did a quick interview with DZone about my new company, InfraDNA, which they published on their website. Thank you DZone for the opportunity!

hudson, infradna

Introducing InfraDNA, the Hudson company

April 26th, 2010

As I wrote in my farewell note, I was working on starting a new company around Hudson. It took longer than I initially anticipated, but it’s finally open for business!

The company will provide two things; one is support, so that I can answer your questions and problem reports in a timely fashion, and the other is consulting, so that I can help you develop custom plugins, or provide on-site support to work on some tricky problems.

The name of the company is InfraDNA because I think of Hudson more as an infrastructure on which all kinds of server-side automation/tools can be built/deployed, and because I think this stuff is built into me (as in DNA) — when I look back my career as a software engineer, I always somehow seem to come back to tooling. (Plus, the domain name was available!)

Looking forward to hearing from you.

hudson, infradna

Hudson console markups

April 14th, 2010

Despite all the report comprehension in Hudson, such as JUnit, PMD, FindBugs, etc., log files still hold a special place in terms of capturing what has really happened. Hudson does a bit of AJAX in this space to let you follow output as it comes, but the log is basically just a plain text that doesn’t really have structures.

But that is changing. One of the recent improvements in Hudson is the infrastructure and extension points for Hudson (and its plugins) to mark up the console output to improve interactivity and do some cool stuff.

I prepared two kinds of extension points for this. One is the ability to scan the console output line by line and add arbitrary markup to it. This can be used for context-independent markup, for example to turn URLs into hyperlinks, look for keywords like “ERROR”, that sort of things.

The other kind is more interesting, where we can place anchors (I call them ‘notes’) at arbitrary points during the output, and those notes can then in turn generate markups. This enables highly context sensitive markups, which I think has a lot of potential.

For example, I started putting a note for every Ant target that gets executed during the Ant execution. I can use this to generate outline for the console output, so that you can jump to the interesting targets, or move up/down to next target very quickly. For simple build scripts, I can let users click the target name and jump to its definition in the build script.

Another place I do this today is when Hudson reports an exception. I can make a stack trace foldable so as not to overwhelm users, and I can also hyperlink each stack trace element to its source file, as a way to encourage people to start hacking Hudson. Or if a build fails, I can present an UI that gives you actions that you might want to take — 1. edit config, 2. rebuild, 3. report to the admin, etc.

With Maven, where Hudson puts a little spying agent inside the Maven process, I can do even better. For example, wouldn’t it be nice if you can hide all the “[INFO]” message with one mouse click? How about a navigation from compilation failure reports to source files? Or if you have an outline of modules that were built and jump to them quickly?

If you are an user, this is just a sneak preview into what will come. If you are a plugin developer, think about all the things you might want to do with this mechanism!