About a week before christmas my Jayway colleges and I went to eat a traditional swedish buffet called Julbord. The wine was good and the food not too vegetarian-hostile and I couldn't help telling those who sat beside me that I've taken over the CM role in my project.
One of the first missions I undertook, as the new CM, was to replace the good old CruiseControl CI with Hudson. I seriously think that Hudson is one of the best things that ever happened to system development. I remember using CruiseControl a few years ago, when people still looked confused when you mention CI, and even worse when you told them it's short for Continuous Integration. Configuring the CC jobs was a lot of work and I kept hoping that my boss would stop asking me to add new jobs or change some configuration or another because it meant diving into this messy xml, trying to manage the confusion that I myself created the last time I tried to fix things out, only to realize that I'd had to rewrite the whole thing from scratch. Again. To me, Hudson was a life saver. It is so easy to create new jobs, to reconfigure existing once, to have a complete overview of all jobs, it's just fun to work with. And then there's the plugins. Hundreds of them, that will help you achieve about anything you can imagine (well, CM kind of thing, anyway.)
Luckily to my colleges, I didn't tell them all that. What I did tell them though, was that I'm looking for some open source project to work with. Since these guys were all Scala-fans, they came up with the idea that I would write a Hudson plugin for running sbt. Sounds good, I said, while trying to google "sbt" in my cell phone without them noticing. sbt turned out to be a fantastic tool that helps you build Scala projects. The sbt developers might have had some bad experience with Maven, because, as I understood, sbt is really easy to configure, is not burdened by xml, and allows you to do miracles, like creating new tasks without the need of plugins. I played a bit with sbt realized that, yep, this is some great software and Hudson should have a plugin fo it.
So I googled sbt+hudson. Other people had also thought of the idea of creating a plugin for it, apparently. One of them twitted that
Hudson/sbt support will be here very, very soon (if not sooner). Another, blogged on
How to build sbt projects with Hudson and integrate test results and another one said he'll
try and get something up on githib in a bit. But I couldn't find anything on Github or anywhere else so I wrote a
mail to the Hudson developer mail list asking them if anyone was working on it or if I should give it a try. I was told by none other than Kohsuke Kawaguchi to go for it, so I sat to read everything I could find about Hudson's plugin development, and the result became the sbt plugin for Hudson.
The plugin is really simple. It lets you choose an sbt launch jar in Hudson's configuration, and then it lets you add a build step in your project, where you can specify sbt build flags and actions. When you ran the project build, you can see sbt do it's magic in Hudson's virtual console and in case sbt fails to build your project, Hudson would fail the build as well.
Now what. That's what I asked myself once this was working. There are a few minor things I'd like to fix in coming releases, like allowing a choice of several sbt jar versions, and to allow automatic download of the sbt jar instead of choosing an existing one. When it comes to test results, I think that the only way to publish them is to add a test listener inside your sbt project, as explaind in
Henkelmann's blogg. It just seems impossible to convince sbt it should create test results from outside the project definition, using arguments. (I also tried saying really loud "
test results, test results" while sbt was building, but this didn't help either.) Once you added a test listener in your sbt project you can let Hudson publish them without any need of my plugin. When it comes to scaladoc, you may as well use Hudson's publish javadoc option, again, without using the sbt plugin.
So if you read this far, (which I'm thankful for) then here's my question to you:
Which features would you like to see in the sbt plugin?
And here are some links:
The sbt plugin on Hudson's wiki
sbt plugin issues on Hudson's jira
sbt plugin on github
See you soon!
