Saturday, February 12, 2011

sbt plugin on Jenkins

So you all know about Jenkins right?

Hudson was renamed to Jenkins and the old Hudson project is now cared for by Oracle. In case you missed the whole thing (hiding under that stone again?) you can read all about it here, here or here.

I consider myself loyal to the creators of Hudson and to it's community, and have followed them to Jenkins, who's site is now available at In the future, if the Hudson API will diverges too much from Jenkins' I have no plans on maintaining my plugins on both branches and will drop it's support in Hudson.

Speaking about the sbt plugin, I have released a new version! The sbt plugin version 1.2 should now be available for download through your Jenkins plugin list. Read all about it in the plugin wiki page.

The biggest news in this release is the supports for multiple sbt launchers. In your Jenkins preferences page, define all of your sbt launchers:

Then, (if you haven't done that already) in your project preferences, add an sbt build step:

Now, choose which sbt launcher to use, add any jvm and sbt flags you need for your build, and specify which actions you want to run. Keep the -Dsbt.log.noformat=true sbt flag to keep the console output clean.

After that, run your project and watch sbt do it's magic on the Jenkins virtual console.

I sure hope you like it. Please let me know if you have any issues with the plugin or if you want to see any features.

And here are some new links:
See you soon!

Friday, January 28, 2011

Hudson, sbt & me

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!

Sunday, January 23, 2011

Hello World

I woke up at 4 AM and couldn't sleep. The reason? I'm was considering different branching strategies for our project. I'd really like to split it into (at least) two separate branches but the problem is that both parts would have dependencies on each other and I would have to update versions in projects in these two branches continuously. Tedious. Maybe a different strategy would be better? Or just keep things as they are?

Another morning, few months ago, I woke up at 4 AM thinking about a hard to break SQL.

This is a blog for  people who wake up at 4 AM because of development issues. Or for people who's like to read about people who wake up at 4 AM. Or for other freaks.

But first let me tell you something about myself and try to explain the coffin thing. I work in a fantastic consultant company called Jayway, currently in a large internet bank project. Our CM was recently too tired of late evenings and endless merging issus and I was asked to take his place. I like being a CM. I just love Hudson and I have some strong feelings (not all positiv though) to Subversion.

I live in Sweden in a place called Kista. Try writing kista in google translate and things might get clearer. 

Here's a list of other thing I like, to help you sort me in the correct box: Java, Scala, my wife and children,  shooting pool[1], swimming, cycling, solving problems.

That's enough for a hello world tryout. More will come soon, hopefully. I'd like to write about how we solved the branches issue. And about being a CM. And about open source. 

See you soon! 

[1] They have this pool table in my current project, not too far from where I sit. How could I ever switch project?