Fun with Hudson, Part 1

I’m building a set of samples for our next release of JDeveloper, and in doing so, I found the need for Hudson. Which is good, because, after my preparations to present on Hudson at Rocky Mountain Oracle User Group, I’ve become a Hudson addict and am dreaming up all kinds of ways it can improve my life! Really, though, I think Hudson is a pretty cool tool to automate all the tasks that need to happen after a developer checks in a bit of code.

A common use case for Hudson is to checkout a project from subversion (or other repository) and then for ADF applications, use the ojdeploy executable to create a JAR, WAR, or EAR of the project. This is useful for cases where the output of one development team is the EAR file, or if you want to hook in auto deployment and always have a deployed version of the application running.

However, my requirement is that the exported source of the application is the build artifact, not an EAR file. I need to give our documentation writers the source (preferably zipped up) for each new build of the application so that they can see the design-time changes that were made to implement whatever feature I’m demonstrating in the sample. I haven’t given our documentation writers access to our subversion server, so they can’t pull the source from there. They want a zipped workspace that they can download, extract, and start working with right away.

It took a little trial and error, but here’s what I came up with: A build task in Hudson that issues the zip command, ignoring ‘.svn’ and ‘builds’ directories:

zip -r $WORKSPACE/builds/$BUILD_TAG * -x ‘*/.svn/*’ -x ‘*builds/*’

This command zips the current workspace directory * (which on my Hudson slave is something like /home/lmunsing/.hudson/jobs/Summit_ADF/workspace), ignoring all the .svn directories which exist at each level, and ignoring the builds directory that I manually created in the workspace directory to hold the zip files. This means I’m getting a zip that doesn’t contain the .svn directories or their contents, and that doesn’t contain the previous build zips. I tried using the tar command, but that gave me really crazy output in the Hudson console, so I went back to zip. I also tried combining the two exclusions according to the doc by space-separating them, but that just didn’t work. I’d end up with zip that included all the previous build’s zips. I also tried doing an svn export, but of course running that from the shell doesn’t pick up the account privileges that are configured in Hudson, and I didn’t want to include the username and password on the command line. I also used the $BUILD_TAG environment variable to name the zip file.

Here’s what the command looks like in the job console (for the 26th build):

zip -r /home/lmunsing/.hudson/jobs/Summit_ADF/workspace/builds/hudson-Summit_ADF-26 builds Model src SummitADF.jws Summit_Extensions ViewController -x ‘*/.svn/*’ -x ‘*builds/*’

This took enough trial and error to get right and google wasn’t giving me help with this exact sweet spot of “.svn directories exclude hudson zip”, so hopefully this helps someone.

Now I need to modify the automated build email to alert the doc writers when a new build has been created and point them to:


I’ll be using the Hudson Email Extension plug-in for that.

The next stage will be to call this shell script only if the application builds, then only if it builds and some JUnit tests (sanity tests) are successful. For that, I’ll use the Hudson Parameterized Trigger plug-in. And of course, report all this back to developers using the Team Productivity Center. Such fun!

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *