Category: build

Total 4 Posts

Send a Subversion Change Log from a Hudson build

For some time, I wanted to send out a Subversion change log from Hudson after a successful build showing all of the changes since the last build. (This is something I think Hudson should support natively – you can see a change log via the UI.) After some research, I came across Using Groovy with Hudson to send rich text email posted by "Chetan".

This solution works like a champ and is recommended. Two points – 1) if you are using Subversion, see the comments for the email template code for displaying the subversion log in the email – the main template code is not for Subversion; 2) I had to change ${fileEntry.editType} which displayed an object reference to ${} to display whether the file was edited, added or deleted.


Broken Build “Awards”

As I have mentioned before, I recently read Raymond Chen’s The Old New Thing: Practical Development Throughout the Evolution of Windows. In an essay entitled "Whimsical embarrassment as a gentle form of reprimand", Raymond discussed the various items someone who breaks the build receives and must keep until someone else breaks the build.

Reflecting on this I have a long history of using minor embarrassment awards to encourage a change in behavior. When I was a Boy Scout, my troop has similar awards. The first was the "Johnny-Come-Lately" award given to the camper who was the last to arrive (late) to an assembly. The recipient was required to wear the award (essentially a large, gaudy necklace) to all meals until it was given to the next recipient. The other award was the "Fly-Baita-Campa" for the messiest tent. I was the "proud" recipient of this award a couple time during my first week at camp.

In terms of broken builds, I have used two different items for awards over the last ten years. The first award was a decoy duck, intended to train retriever dogs, of a wounded duck. The duck appeared to have a broken neck and a gunshot wound. Truly, a fitting symbol of a broken build. The second award, and one I used for over seven years, was a rubber chicken. We referred to it as "Dopey, the Chicken of Shame". Dopey because most broken build were due to stupid mistakes. The chicken of shame because of the embarrassment of receiving it.

Raymond’s original post can be found here.


Hudson – Continuous Integration Tool

In my current position, we use perl extensively. There isn’t much of a build process — check out the code, set a couple variables, run a suite of tests. (There is always the perl -c command line option which will perform a syntax check but I want something more exhaustive.) A former colleague of mind pointed me at Hudson, a tool they recently started using. They are a java shop and Hudson is definitely aimed at java shops. Below are the details of my initial experience with Hudson.

Proof of Concept

I downloaded the Hudson WAR file (version 1.176) to my desktop machine. From a command line prompt, I launched Hudson with the command java -jar hudson.jar. I minimized the command prompt window and launched my browser to the default http:\\localhost:8080 which displays the Hudson configuration pages. Here, I created a new job and filled in the following:

  • Project Name
  • Project Description
  • Subversion Repository URL
  • WebSVN URL
  • Set up poll SCM (check for updates) on once a minute schedule)
  • Selected execute Windows batch commands with the necessary commands to run my perl tests
  • Select email notification

That is pretty much what ot took to get up and running. I had a few mistakes in the commands under “Windows Batch Commands” but once that was complete, I was able to get a successful build. (Here successful is defined as the last command executed returning with a non-zero exit code.) The email did not work at first. I needed to go back to the home page and select “Manage Hudson”, “System Configuration” to then set up my email server credentials.

I thought all was well until my first unattended build. The build failed with the message “ERROR: Failed to update…” from the Subversion checkout. I did some research and found some references to the same error in one of the packages that Hudson uses. There was a suggested fix but it required I code change. I filed a bug and a new build was available within a couple of days which fixed my problem.

Move into Production

After running the build on my local machine for a few days, I decided it was worth moving into our normal processes. I installed it on a Windows server. There is a good description on how to setup Hudson as a Windows service in the Hudson wiki.

We have been running Hudson now for a few weeks and I am very pleased. Highly recommended.


Ant signjar error: keystore load: Too many certificates in chain

I just ran into an error building our system using ant while documenting building a project under Windows. (Normally, we build under Unix).

The error was coming from the Ant signjar task:

jarsigner error: java.lang.RuntimeException: keystore load: Too many certificates in chain

A google search turned up multiple references to the string “Too many certificates in chain” but only one hit to this error with regards to the signjar task. Even then, that reference did not contain a solution. I investigated further and realized that when the keystore was checked into CVS, keyword expansion was not set to binary on the file. When the file is checked out on our Unix build machine, the keyword expansion was not causing an error. When the file is checked out on a Windows box, the keyword expansion breaks the build. Changing the keyword expansion to binary fixed the error.