build failures usually indicate either a chronic configuration issue or poor developer practices (for
example, developers committing changes without checking that it works locally first).
You can also opt to send a separate email to any developers who have committed changes to the broken
build. This is generally a good idea, as developers who have committed changes since the last build are
naturally the people who should be the most interested in the build results. Jenkins will get the email
address of the user from the currently-configured security realm (see Section 7.4, “Security Realms—
Identifying Jenkins Users”), or by deriving the email address from the SCM username if you have set
this up (see Section 4.8, “Configuring the Mail Server”).
If you use this option, it may be less useful to include the entire team in the main distribution list. You
may want to simply include people who will be interested in monitoring the result of every build (such
as technical leads), and let Jenkins inform contributing developers directly.
This assumes of course that the changes caused the build failure, which is generally (but not always)
the case. However, if the builds are infrequent (for example, nightly builds, or if a build is queued for
several hours before finally kicking off), many changes may have been committed, and it is hard to
know which one was actually responsible for the build failure.
Not all builds are alike when it comes to email notification. Developers committing changes are
particularly interested in the results of the unit and integration test builds (especially those triggered by
their own changes), whereas BAs and testers might be more interested in keeping tabs on the status of the
automated acceptance tests. So the exact email notification setup for each build job will be different. In
fact, it is useful to define an email notification strategy. A sample of such an email notification strategy
is outlined here:
- Fast builds (unit/integration tests, runs in less than 5 minutes): notification is sent to the team lead
and to developers having committed changes. - Slow builds (acceptance tests builds, run after the fast builds): notification is sent to team lead,
testers and developers having committed changes. - Nightly builds (QA metrics, performance tests and so on; only run if the other builds work): all
team members—these provide a snapshot picture of project health before the daily status meeting.
Indeed, you should consider what notification strategy is appropriate for each build job on a case-by-
case basis, rather than applying a blanket policy for all build jobs.
8.3. More Advanced Email Notification
By default, Jenkins email notification is a rather blunt tool. Notification messages are always sent to
basically the same group of people. You cannot send messages to different people depending on what
went wrong, or implement any sort of escalation policy. It would be useful, for example, to be able to
notify the developers who committed changes the first time a build breaks, and send a different message
to the team lead or the entire team if the build breaks a second time