John is an experienced consultant specialising in Enterprise Java, Web Development, and Open Source technologies, currently based in Sydney, Australia. Well known in the Java community for his many published articles, and as author of Java Power Tools and Jenkins: The Definitive Guide, and founder of the open source Thucydides Automated Acceptance Test Library project, John helps organisations to optimize their Java development processes and infrastructures and provides training and mentoring in agile development, automated testing practices, continuous integration and delivery, and open source technologies in general. John is the CEO of Wakaleo Consulting, and runs several Training Courses on open source Java development tools and best practices. John is a DZone MVB and is not an employee of DZone and has posted 125 posts at DZone. You can read more from them at their website. View Full User Profile

Kickass Hudson Plugins - Part 1 - Setenv and the Description Setter

10.07.2009
| 6425 views |
  • submit to reddit

One of the awesome things about Hudson is the sheer number of plugins available. In fact, if you use Hudson, make a habit of checking out the list of available plugins every month or so - there's bound to be something new that you could use! In this article, I explore two relatively new ones: the Setenv plugin and the Description Setter plugin.

The Setenv plugin

Many build scripts use environment variables for a variety of purposes, particularly legacy, Ant-based ones. Some use them to determine the server the build is running on, the target environment, or where certain tools are installed. Still others use shell scripts to do a variety of initial work before the Ant or Maven kick off. This may or may not be a good build scripting practice, but when you are migrating projects onto Hudson, you may well find yourself needing to make it work.

This is actually quite tricky to do in Hudson. You can set environment variables that apply across all projects, but this is a little heavy-handed. You can pass properties into Ant and Maven build jobs, but not to shell scripts. You can use an Ant script to bootstrap the environment by initializing environment variables, and then invoking the shell script, but this is hardly an elegant solution. However, you can now do this with the Setenv plugin. This plugin lets you define environment properties on a per-project basis, and works fine with any kind of build job:

 

The Description Setter plugin

Have you ever wondered what version of your application was built by a particular build? Or what build was responsible for a particular version? Sure, you can go into the log files, but this is not exactly a user-friendly solution. The Description Setter plugin now lets you do something much nicer.

This plugin lets you extract a text from the output of your build jobs, using a regular expression, and assign that text automatically to the build job description. The trick is to identify the label you want to extract from your build output, and find a regular expression that will isolate it. For example, if you are using the Maven Release plugin, your build output will contain a line like the following:

... [INFO] Uploading project information for killer-app 1.2.3 ...

With the Descriptor Setting plugin, you can set up a regular expression like the following to isolate the build number. You can put use multiple regular expressions, just remember to enclose the one you want to use as a label in parentheses, as shown here:

Once you have done this, your builds will automatically be labelled with the text extracted from the build output:

And, if there where any doubts that Hudson plugin developers have a sense of humor, check out the Chuck Norris plugin. This lets you add an appropriately grim or cheerful picture of Chuck Norris to your build jobs, along with a Chuck Norris programming quote.

From http://weblogs.java.net/blog/johnsmart/

Published at DZone with permission of John Ferguson Smart, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Michael Parmeley replied on Wed, 2009/10/07 - 2:01pm

ANT is "legacy"? What makes you think that?

Steven Baker replied on Wed, 2009/10/07 - 5:49pm in response to: Michael Parmeley

because it is...

Mladen Girazovski replied on Thu, 2009/10/08 - 7:35am

 ANT is "legacy"? What makes you think that?

 Thats not what he said:

Many build scripts use environment variables for a variety of purposes, particularly legacy, Ant-based ones.

And no, Ant is not legacy, altough i'm a Maven2 fan.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.