Let Jenkins Keep You Notified! (with the Instant Messaging Plugin)

There are times when email just isn’t fast enough… actually, as a developer, there are times when you just don’t want to have your email open, as it can be too big a source of distraction. Your manager emails you with some “urgent” question that needs answering right now… but you know what, answering that email will take you right out of the zone that you just spent the last three hours chasing. Far better to let Jenkins notify you via a different route. To help keep a level of commonality between the various instant messaging plugins (i.e. the Jabber or the IRC plugins), the Instant Messaging plugin provides a common API and UX for reuse by instant messaging plugins.

So, the short story is that this is an enabling plugin with no real user-visible functionality, but if you are wondering what this plugin is doing on your Jenkins instance, it is providing some of the core functionality used by the JabberIRC, etc. plugins.

Stable Release Versions
The latest release is 1.21 which was released in November 2011 and has no known problems.

Requirements for Plugin-Use
Jenkins 1.392 or newer.

Step-by-Step Instructions on How to Use the Instant Messaging Plugin

Just install one of the plugins that depend on this plugin (i.e. the Jabber or the IRC plugin) and Jenkins will automatically download and install this plugin.

Nothing to configure specifically for the Instant Messaging plugin. The plugins that depend on the Instant Messaging plugin provide their own configuration options using some of the core functionality provided by this plugin.  

“Nothing to see here, move along now please!”

Well, ok, there are a number of common features that dependent plugins expose.

You can choose when to send build notifications: 

  • every build (a.k.a. all); 
  • every failure (a.k.a. failure); 
  • every failure and when first fixed (a.k.a. failure and fixed); or 
  • every time the build status changes (a.k.a. change)

You can choose who to notify: 

  • people who committed a change that caused the build to transition from stable to failed/unstable (a.k.a broken); 
  • people who committed a change to the project since the build transitioned from stable to failed/unstable (a.k.a. culprits); 
  • people who committed a change that caused the build to transition from failed/unstable to stable (a.k.a. fixers); 
  • people who committed a change to a job where the job’s artifacts have been fingerprinted as used in this job (a.k.a. upstream committers

Tips & Tricks

  • You can control various features of Jenkins jobs by interacting with the bot provided by the Instant Messaging plugin (and exposed by one of its dependent plugins). You give the bot a command by either addressing it in a chat room or by sending it a private message which includes the command prefix.

    For example, if the command prefix is ! then to schedule a new build of the “Super Whizzo” job, you would send the bot an instant message like

    !build ‘Super Whizzo’

    You can find out what the bot can do with the



Known Issues

  • If you allow builds of the same job to run in parallel, this plugin will force subsequent builds to wait for previous builds to complete, as it needs to know the result of the previous build before it can notify the result of a build.

    This is only really an issue if your build execution time can vary wildly and you have push notification enabled. For example, developer Joe commits a change triggering build #367 and 10 seconds later developer Mic commits a change triggering build #368. With parallel execution of builds in a job, build #367 triggered by Joe could end up running on a slower slave than the build #368, such that build #368 is ready to notify before build #367… but part of the notification relies on the status of build #367, so that build #368 will not be able to finish until build #367 finishes.

Relevant Documentation

Stephen Connolly
Elite Developer and Architect




Blog Categories: 

Add new comment

Having trouble subscribing in Chrome?