Par défaut, la notification par email Jenkins est un outil plutôt brut. Les messages de notification sont toujours envoyés au même groupe de personnes. Vous ne pouvez pas envoyer des messages à différentes personnes en fonction de ce qui a mal tourné. De la même façon, vous ne pouvez pas mettre en œuvre des politiques d'escalade. Par exemple, il pourrait être utile d'être en mesure de notifier les développeurs qui ont committé les modifications la première fois qu'un build échoue, et envoyer un message différent au chef d'équipe ou à l'équipe entière si le build échoue une seconde fois

Le plugin Email-ext vous permet de définir une stratégie de notification par email plus fine. Ce plugin ajoute une case Editable Email Notification (voirFigure 8.2, “Configurer les notifications par email avancées”), qui remplace efficacement la notification par email standard de Jenkins. Ainsi, vous pouvez définir une liste de destinataires par défaut et affiner le contenu du message électronique. Vous pouvez aussi définir une stratégie de notification plus précise avec des messages différents pour des listes de destinataires différents suivant les évènements. Notez qu'une fois que vous avez installé et configuré ce plugin pour votre tâche de build, vous pouvez désactiver la configuration normale de notification par email.

Ce plugin a deux fonctionnalités liées mais distinctes. Tout d'abord, il vous permet de personnaliser le message de notification par email. Vous pouvez choisir parmi un grand nombre de mots clés prédéfinis pour créer vos propres titres et corps de messages personnalisés. Vous incluez un mot clé dans votre modèle de message en utilisant la notation habutuelle dollar (e.g., ${BUILD_NUMBER} ou $BUILD_NUMBER). Certains mots clés acceptent des paramètres que vous pouvez spécifier en utilisant le format name=value (ex : ${BUILD_LOG, maxLines=100} ou${ENV, var="PATH"}). Les mots clés les plus utiles sont:

Pour obtenir la liste complète des mots clés disponibles ainsi que leurs options pour ceux qui acceptent des paramètres, cliquez sur l'icône d'aide en face de Contexte Token Reference.

Le bouton Avancé vous permet de définir une stratégie de notification plus sophistiquée basée sur le concept de déclencheurs (voirFigure 8.3, “Configurer les déclencheurs de notification par email”). Les déclencheurs déterminent quand les notifications par email doivent être envoyées. Les déclencheurs supportés sont les suivants :

Vous pouvez configurer autant (ou aussi peu) de déclencheurs que vous le souhaitez. La liste des destinataires et le modèle de message peuvent être personnalisés pour chaque déclencheur, par exemple en utilisant les déclencheurs Still Failing et Still Unstable, vous pouvez mettre en place une stratégie de notification qui n'avertit que le développeur qui a committé des changements la première fois qu'une tâche de build échoue, mais continue par informer le chef d'équipe si elle échoue une seconde fois. Vous pouvez choisir d'envoyer le message uniquement à des développeurs qui ont committé lors du build (« Send to committers »), ou d'inclure également tous ceux qui ont committé depuis le dernier build avec succès. Cela assure que tous ceux qui peuvent être impliqués dans l'échec du build seront notifiés de façonappropriée.

Vous pouvez également personnaliser le contenu du message en cliquant sur l'option More Configuration (comme indiqué pour le déclencheur Still Failing dans Figure 8.3, “Configurer les déclencheurs de notification par email”). De cette façon, vous pouvez personnaliser des messages différents qui seront envoyés dans des cas distincts.

Les déclencheurs interagissent intelligemment entre eux. Donc, si vous configurez à la fois le déclencheur Failing et le déclencheur Still Failing, seul le déclencheur Still Failing sera activé lors du second échec de build.

Un exemple d'un tel message personnalisé est illustré dans Figure 8.4, “Message de notification personnalisé”.

Toutefois, l'email n'est pas une stratégie de notification sans défaut. Certains développeurs ferment par moment leurs clients de messagerie afin d'éviter d'être interrompu. Dans les grandes organisations, le nombre d'emails qui arrivent chaque jour peut être considérable et les notifications d'échec de de build peuvent être cachées parmi une foule d'autres messages moins importants. Les échecs de build peuvent donc ne pas toujours avoir l'attention prioritaire qu'ils nécessitent dans un environnement d'intégration continue finement réglé. Dans les sections suivantes, nous nous pencherons sur certaines stratégies de notification autres qui peuvent être utilisées pour augmenter la sensibilisation des équipes sur les builds échoués et encourager les développeurs à les corriger plus rapidement.