Chapter 8. Notification
8.1. Introduction
While it is important to get your build server building your software, it is even more important to get
your build server to let people know when it can’t do so. A crucial part of the value proposition of
any Continuous Integration environment is to improve the flow of information about the health of your
project, be it failing unit tests or regressions in the integration test suite, or other quality related issues
such as a drop in code coverage or code quality metrics. In all cases, a CI server must let the right people
know about any new issues, and it must be able to do so fast. This is what we call Notification.
There are two main classes of notification strategies, which I call passive and active (or pull/push).
Passive notification (pull) requires the developers to consciously consult the latest build status, and
includes RSS feeds, build radiators, and (to a certain extent) emails. Active notification (push) will pro-
actively alert the developers when a build fails, and includes methods such as desktop notifiers, chat,
and SMS. Both approaches have their good and bad points. Passive notification strategies such as build
radiators can raise general awareness about failed builds, and help install a team culture where fixing
broken builds takes a high priority. More direct forms of notification can actively encourage developers
to take matters into their own hands and fix broken builds more quickly.
8.2. Email Notification
Email notification is the most obvious and most common form of CI notification. Email is well-known,
ubiquitous, easy to use and easy to configure (see Section 4.8, “Configuring the Mail Server”). So,
when teams set up their first Continuous Integration environment, it is usually the most common initial
notification strategy they try.
You activate email notification in Jenkins by ticking the E-mail Notification checkbox and providing
the list of email addresses of the people who need to be notified (see Figure 8.1, “Configuring email
notification”). By default, Jenkins will send an email for every failed or unstable build. Remember, it
will also send a new email for the first successful build after a series of failed or unstable builds, to
indicate that the issue has been fixed.
Figure 8.1. Configuring email notification
Normally a build should not take too many tries to get working again—developers should diagnose and
reproduce the issue locally, fix it locally, and only then commit their fix to version control. Repeated