Si votre instance Jenkins s'exécute sur une machine qui est physiquement située à proximité de l'équipe de développement, vous pouvez aussi vouloir ajouter les sons dans l'ensemble des stratégies de notification. Cela peut être une stratégie efficace pour les petites équipes co-localisées, mais cela devient plus difficile si le serveur de build est mis en place sur une machine virtuelle ou ailleurs dans le bâtiment.

Il y a deux façons d'intégrer des retours audio dans votre processus de build Jenkins : le plugin Jenkins Sounds et le plugin Jenkins Speaks. Les deux peuvent être installés via la page du gestionnaire de plugins de la manière habituelle .

Le plugin Jenkins Sounds est le plus flexible des deux. Il vous permet de construire une stratégie de communication détaillée basée sur le dernier résultat de build et aussi (facultatif) sur le résultat du précédent build (voir Figure 8.28, “Configurer les règles de Jenkins Sounds dans une tâche de build”). Par exemple, vous pouvez configurer Jenkins pour jouer un son la première fois qu'un build échoue, un son différent si le build échoue une seconde fois, et encore un autre son lorsque le build est corrigé.

Pour le mettre en place, vous devez cocher Jenkins Sounds à la section des actions post-build dans la page de configuration de la tâche de build. Vous pouvez ajouter autant de règles de configuration audio que vous le souhaitez. L'ajout d'une règle est assez simple. Vous devez tout d'abord choisir quel résultat de build va déclencher le son. Vous devez également spécifier les résultats de build précédents pour lequel la présente règle est applicable: Non Construit (NB), Avorté (Ab), Échec (Fa), Non-positif (ONU) ou Réussi (Su).

Le plugin Jenkins Sounds propose une grande liste de sons prédéfinis qui offrent généralement beaucoup de choix pour les administrateurs de build les plus exigeants. Vous pouvez cependant ajouter votre propre son à la liste si vous le voulez. Les fichiers sonores des sons sont stockés dans un fichier ZIP ou JAR sous une structure plate (pas de sous-répertoire). La liste des sons proposés par le plugin est tout simplement la liste des noms de fichiers auxquels on retire l'extension. Le plugin supporte les formats AIFF, AU, et WAV.

Dans la page de configuration système, vous pouvez indiquer à Jenkins un nouveau fichier d'archive de sons en utilisant la notation http:// si votre archive de sons est disponible sur un serveur Web local, ou la notation file:// s'il est disponible en local (voir Figure 8.29, “Configurer Jenkins Sounds”). Une fois que vous avez sauvé la configuration, vous pouvez tester les sons de votre archive via le bouton Test Sound dans la section Avancé.

Le plugin Jenkins Sounds est un excellent choix si vous voulez compléter vos techniques de notification plus classiques. Les sons courts et reconnaissables sont un excellent moyen pour attirer l'attention d'un développeur et permettre à l'équipe de savoir que quelque chose doit être réparé. Ils seront alors un peu plus attentifs lorsque les notifications plus détaillées suivront.

Une autre option est le plugin Jenkins Speaks. Avec ce plugin, vous pouvez demander à Jenkins de diffuser une annonce personnalisée (avec une voix très robotique) lorsque votre build échoue (voir Figure 8.30, “Configurer Jenkins Speaks”). Vous pouvez configurer le message exact à l'aide de Jelly. Jelly est un langage de script basé sur XML largement utilisé dans les niveaux inférieurs de Jenkins.

L'avantage de cette approche réside dans sa précision : puisque vous pouvez utiliser des variables Jenkins dans le script Jelly, vous pouvez demander à Jenkins de dire ce que vous voulez sur l'état de la construction. Voici un simple exemple :

<j:choose>
            <j:when test="${build.result!='SUCCESS'}">
            Votre attention, s'il vous plait. Le projet ${build.project.name} a échoué
            <j:if test="${build.project.lastBuild.result!='SUCCESS'}"> encore</j:if>
            </j:when>
            <j:otherwise><!-- Ne rien dire --></j:otherwise>
            </j:choose>

Si vous laissez ce champ vide, le plugin va utiliser un modèle par défaut que vous pouvez configurer sur la page de configuration du système. En fait, c'est généralement une bonne idée de faire cela, et seulement d'utiliser script spécifique à un projet si c'est nécessaire.

L'inconvénient est que la voix robotique est parfois peut être un peu difficile à comprendre. Pour cette raison, c'est une bonne idée de commencer votre annonce par une phrase générique telle que "Votre attention s'il vous plaît», ou à combiner Jenkins Speak avec le plugin Jenkins Sounds, de façon à attirer l'attention des développeurs avant que le message réel ne soit diffusé. L'utilisation de traits d'union dans les noms de projets (par exemple, jeu-de-vie plutôt que jeudevie) aidera aussi le plugin à savoir comment prononcer vos noms de projet.

Ces deux approches sont utiles pour les petites équipes, mais peuvent être limitées pour les plus grosses, lorsque le serveur n'est pas physiquement situé à proximité de l'équipe de développement. Les futures versions pourront supporter la lecture de sons sur une machine séparée, mais au moment de la rédaction de ce livre ce n'est pas encore disponible.