In an earlier post, I wrote about configuring notifications with Hudson. This is a follow-up post to demonstrate how to set up even more fine-grained notification control using the Hudson Email Extension Plugin.
In a nutshell, this provides granular control over:
- Who receives notifications at any event: build instability, build failure, return to stability, continuing failure, etc.
- The subject of the notifications that are sent
- The content of notifications that are sent
By default, as of this writing, Hudson’s email notifications are fairly basic. It will notify either a specified list of recipients or “culprits” when a build fails. It will contain a generic subject and message, basically indicating that a build failed, but with no details.
The Email Extension Plugin: What it gets you
The Email Extension Plugin will enable you to control the content of the subject and message to make them more meaningful, in addition to the more granular controls I mentioned above.
Here’s what your “Configure Project” screen will look like once you install the plugin:
Notice from this screenshot how you can add notifications on different triggers: “Unstable”, “Still Failing”, etc. You can specify who should receive messages for all of the available events. You can add a new event by selecting one of the available options in the “Add a trigger” Select list.
Once you do so, you get checkboxes for the recipients to select. In addition, you get fields for controlling the subject and message. You can specify all manner of variables in there. My current setup at work for message content is:
With these variables, on the events I have specified, I get to see what tests have failed and what code changes have happened since the last build. Other variables are available to you. As per Hudson’s conventions, simply click on the (?) icon beside the configuration to get all the details for how to use the plugin. Here’s a sample of what you currently get in the Help:
I wrote before about how Hudson can significantly aide in noise control. I think this plugin gets you even further. Consider the “default case”: you get a notification that a build failed. Now you have to go research why it failed. This means going to your Hudson URL, checking the failed tests, and determining responsibility. However, with the plugin, I believe determining responsibility cuts out a few steps: it lets you see a) what tests failed and b) what code changed in a single email. All the information you and your team need to assign responsibility is, potentially, in a single communication.
So what? I think the answer to that question resides squarely in the answer to another question: how much do you value your time?
How to Install
You install this plugin just like you install other Hudson plugins, thank God (I Love Hudson. I wish all software I worked with were as easy to extend.)
- click the Hudson link, “Manage Hudson”, “Manage Plugins”
- in the “available” tab, select “Hudson Email Extension Plugin”
- select it, and click checkboxes and OK buttons until it’s installed. Restart Hudson
Once it’s installed, you go into your project configuration and now you have more “Advanced” buttons and such in the Notifications area than you had before. From there, it’s a matter of selecting your triggers and what you want to happen on those triggers.
If you want even more noise control, and more meaningful communication, take the few minutes to install the Hudson Email Extension Plugin.
This is useful stuff but I can't get the extended email plugin to successfully do SMTP authentication even tho' the regular email system in Hudson can authenticate against the same SMTP server with the same credentials. Thanx for posting about Hudson anyway!
Sean, have you posted this to the Hudson newsgroup? Seems like something that either *should* work or needs to be fixed
Another mailing list I suppose I need to be on... *sigh*
Just installed this plugin and started using it but still trying to figure out how to configure it with upstream and downstream jobs. The thing I'm still trying to figure out is how an upstream job of SVN updating a webapp and a downstream job of just running the MXUnit tasks can communicate back and forth who committed what and what tests failed so that the info can be encapsulated in the emails.
I'm now dealing with Hudson fingerprinting files, plugin to mail upstream committers, jobs triggering other jobs, etc. My original Hudson installation based on your CI postings has now gotten a lot more complicated. Off to the Hudson newsgroups.... sigh.
Bim, I'll be honest: I've not done anything like you're describing. I wish I could help, but... alas. I have thus far kept everything very simple for me, keeping all jobs separate and non-reliant on other jobs.
I hope you get some good answers on the hudson newsgroup. If you finally do figure out how to do what you're trying to do, please do share it.
Post a Comment