Figure 8.4. Customized notification message
Overall, however, as a notification strategy, email is not without its faults. Some developers shut down
their email clients at times to avoid being interrupted. In large organizations, the number of email
messages arriving each day can be considerable, and build failure notifications can be hidden among a
host of other less important messages. So build failures may not always get the high-priority attention
they require in a finely-tuned CI environment. In the following sections, we will look at some other
notification strategies that can be used to raise team awareness of failed builds and encourage developers
to get them fixed faster.
8.4. Claiming Builds
When a build does fail, it can be useful to know that someone has spotted the issue and is working on it.
This avoids having more than one developer waste time by trying to fix the same problem separately.
The Claim plugin lets developers indicate that they have taken ownership of the broken build, and are
attempting to fix it. You can install this plugin in the usual way. Once installed, developers can claim a
failed build as their own, and optionally add a comment to explain the suspected cause of the build and
what the developer intends to do about it. The claimed build will then be marked as such in the build
history, so that fellow developers can avoid wasting time with unnecessary investigation.
To activate claiming for a build job, you need to tick the “Allow broken build claiming” option in the
build job configuration page. From this point on, you will be able to claim a broken build in the build
details page (see Figure 8.5, “Claiming a failed build”). Claimed builds will display an icon in the build
history indicating that they have been claimed. You can also make a build claim “sticky,” so that all