L'une des exigences les plus évidentes sur une tâche de build est de faire des rapports sur les résultats des tests. Non seulement s’il y a des échecs aux tests, mais aussi combien de tests sont exécutés, en combien de temps, et ainsi de suite. Dans le monde Java, JUnit est la librairie de test la plus couramment utilisée, et le format XML JUnit pour les résultats de test est très utilisé et aussi bien compris par les autres outils.

Jenkins fournit un grand support pour les rapports de test. Dans une tâche de build freestyle, vous devez cocher l’option « Publier le rapport des résultats de tests JUnit », et fournir un chemin vers vos fichiers de rapport JUnit (voir Figure 5.32, “Rapport sur les résultats de tests”). Vous pouvez utiliser une expression générique (comme **/target/surefire-reports/*.xml dans un projet Maven) pour inclure les rapports JUnit depuis un grand nombre de répertoires différents — Jenkins agrégera les résultats dans un seul rapport.

Nous regarderons les tests automatisés plus en détail dans le chapitre Chapter 6, Tests automatisés.

A quelques exceptions près, le but principal d’une tâche de build est généralement de construire quelque chose. Dans Jenkins, nous appelons cette chose un artefact. Un artefact pourrait être un exécutable binaire (un fichier JAR ou WAR pour un projet Java, par exemple), ou certains autres livrables liés, comme de la documentation ou du code source. Une tâche de build peut stocker un ou plusieurs différents artefacts, gardant uniquement la dernière copie ou chaque artefact tous les builds.

Configurer Jenkins pour stocker vos artefacts est simple — cochez la case à cocher « Archiver les artefacts » dans les Actions à la suite de build, et spécifier quels artefacts vous voulez stocker (voir la figure Figure 5.33, “Configurer les artefacts de builds”).

Dans le champ « Fichiers à archiver », vous pouvez spécifier les chemins complets des fichiers que vous souhaitez archiver (relatif au répertoire de travail de la tâche de build), ou, utiliser un caractère générique (ex. : **/*.jar, pour tous les fichiers JAR, n’importe où dans le répertoire de travail). L’un des avantages d’utiliser des caractères génériques est qu’il permet de rendre votre build moins dépendant de votre configuration de gestion de version. Par exemple, si vous utilisez Subversion (voir la section Section 5.4, “Configurer la Gestion du Code Source”), Jenkins va parcourir votre projet directement depuis le répertoire de travail, ou depuis un sous-répertoire, en fonction de votre configuration. Si vous utilisez un caractère générique comme **/target/*.war, Jenkins trouvera le fichier indépendamment du répertoire où est positionné le projet.

Comme d’habitude, le bouton Avancé donne accès à quelques options supplémentaires. Si vous utilisez un caractère générique pour trouver vos artefacts, vous pourriez avoir besoin d’exclure certains répertoires dans la recherche. Vous pouvez faire ceci en remplissant le champ Exclusions. Vous entrez un modèle de nom de fichier que vous ne souhaitez pas archiver, même s’ils seraient normalement inclus par le champ "Fichiers à archiver".

Les artefacts archivés peuvent prendre beaucoup de place sur le disque, en particulier si les builds sont fréquents. Pour cette raison, vous pouvez vouloir garder uniquement le dernier en succès. Pour faire ceci, il suffit de cocher l’option « Supprime tous les artefacts, à l'exception du dernier artefact stable ou construit avec succès, afin de gagner de l'espace disque ». Jenkins gardera les artefacts des derniers builds stables (s’il y en a). Il gardera aussi les artefacts du dernier build instable construit juste après un build stable (s’il y a), et également du dernier build en échec qui est arrivé.

Les artefacts de build archivés apparaissent sur la page des résultats de build (voir la figure Figure 5.34, “Les artefacts de build sont affichés sur la page de résultat d’un build et la page d’accueil d’un job”). Les artefacts de build les plus récents sont aussi affichés dans la page d’accueil d’un job.

Vous pouvez aussi utiliser les URLs permanentes pour accéder aux artefacts de build les plus récents. Il s'agit d'une excellente façon de réutiliser les derniers artefacts de vos builds, que ce soit depuis des tâches de build Jenkins ou depuis des scripts externes, par exemple. Trois URLs sont disponibles : dernier build stable, dernier build en succès et dernier build construit.

Avant que nous regardions les URLs, nous devrions discuter du concept de builds stables et en succès.

Un build est en succès lorsque la compilation n’est pas signalée en erreur.

Un build est considéré stable s’il a été construit avec succès, et qu’aucun éditeur ne l’a signalé comme instable. Par exemple, dépendamment de votre configuration de projet, des échecs de tests unitaires, une couverture de code insuffisante, ou d’autres problèmes de qualité de code, peuvent provoquer la mise à l’état instable d’un build. Donc un build stable est toujours en succès, mais l’inverse n’est pas nécessairement vrai — un build peut être en succès sans être nécessairement stable.

Un build complet est simplement un build qui a fini, peu importe son résultat. A noter que l’étape d’archivage aura lieu quel que soit le résultat de la construction.

Le format des URLs d’artefact est intuitif, et prend la forme suivante :

C’est mieux illustré par quelques exemples. Supposez que votre serveur Jenkins est démarré sur http://myserver:8080, votre job de construction se nomme game-of-life, et vous stockez un fichier appelé gameoflife.war, qui est dans le répertoire target de votre répertoire de travail. Les URLs pour cet artefact seraient les suivantes :

Les artefacts peuvent ne pas juste être des exécutables binaires. Imaginez, par exemple, que votre processus de build implique de déployer automatiquement tous les builds sur un server de test. Pour plus de commodités, vous voulez garder une copie du code source exact associé à chaque fichier WAR déployé. Une manière de faire cela serait de générer le code source associé à un build, et d’archiver à la fois ce fichier le fichier WAR. Nous pouvons faire ceci en générant le fichier JAR contenant le code source de l’application (par exemple, en utilisant le Maven Source Plugin pour un projet Maven), et ensuite inclure celui-ci dans la liste des artefacts à stocker (voir la figure Figure 5.35, “Archiver le code source et un paquet binaire”).

Bien sûr, cet exemple est un peu académique : il serait probablement plus simple de juste utiliser le numéro de révision pour ce build (qui est affiché sur la page de résultat du build) pour retrouver le code source depuis votre système de gestion de version. Mais vous voyez l’idée.

Notez que si vous utiliser un gestionnaire de dépôt d’entreprise comme Nexus ou Artifcatory pour stocker vos artefacts binaires, vous n’auriez pas besoin de les garder sur le serveur Jenkins. Vous pourriez simplement préférer déployer automatiquement vos artefacts dans votre gestionnaire de dépôt d’entreprise dans le cadre de la construction de votre job, et de les y retrouver lorsque c’est nécessaire.

Le but d’un serveur IC est de permettre d’informer les gens lorsqu’un build est rompu. Dans Jenkins, cela se passe dans la rubrique Notification.

Jenkins fournit le support des notifications par email. Vous pouvez l’activer en cochant la case à cocher « Notifier par email »dans les actions à la suite du build (voir Figure 5.36, “Notification par email”). Ensuite, entrez les adresses emails des membres de l’équipe qui doivent savoir lorsqu’un build est rompu. Lorsqu’un build est rompu, Jenkins enverra un message amical aux utilisateurs dans la liste contenant un lien vers les builds rompus.

Vous pouvez aussi opter pour envoyer un email séparé à l’utilisateur dont le commit à (probablement) rompu le build. Pour que cela fonctionne, vous devez avoir activé la sécurité dans votre serveur Jenkins (voir la figure Chapter 7, Sécuriser Jenkins).

Normalement, Jenkins enverra une notification par email à chaque fois qu’un build échouera (par exemple, à cause d’une erreur de compilation). Il enverra aussi une notification lorsque le build devient instable pour la première fois (par exemple, s’il y a des tests en échecs). A moins que vous le configurer pour faire ça, Jenkins n’enverra pas d’emails pour chaque build instable, mais uniquement pour le premier.

Finalement, Jenkins enverra un message lorsque un build précédemment en échec ou instable réussi, pour permettre d’informer tout le monde que le problème a été résolu.

Vous pouvez aussi démarrer d’autres constructions de job dans les actions à la suite du build, en utilisant l’option « Construire d’autres projets (projets en aval) ». Ceci est utile si vous souhaitez organiser votre processus de build en plusieurs, plus petites étapes, à la place d’une seul longue construction de job. Il suffit de lister les projets que vous souhaitez démarrer après celui-ci. Normalement, ces projets seront déclenchés uniquement si le build est stable, mais vous pouvez optionnellement déclencher d’autre construction de job même si le build courant est instable. Cela peut être utile, par exemple, si vous voulez démarrer une construction de job effectuant des rapports sur des mesures de qualité de code après une construction de job principal du projet, même s’il y a des tests en échecs dans le build principal.