Les tâches de build free-style vous permettent la configuration la plus flexible, et sont votre unique option pour des projets non Java.

Lorsque vous utilisez le plugin Violations avec une tâche de build free-style, vous devez spécifier les chemins de chaque rapport XML généré par les outils d’analyse de code statiques que vous avez utilisé (voir Figure 9.4, “Configurer le plugin violation pour un projet free-style”). Le plugin peut répondre à plusieurs rapports depuis le même outil, ce qui est utile pour des projets Maven multi-module — il suffit alors d’utiliser une expression générique pour identifier les rapports que vous voulez (par exemple, **/target/checkstyle.xml).

Le plugin Violations génèrera un graphique de suivi pour chaque type de problème au cours du temps (voir Figure 9.5, “Les violations au cours du temps”). Le graphique affiche une ligne de différente couleur pour chaque type de violations que vous suivez, ainsi qu’un résumé des derniers résultats.

Vous pouvez aussi cliquer sur le graphique pour vous rendre à un build particulier. Ici, vous pouvez voir le nombre de problèmes soulevés pour un build particulier (voir Figure 9.6, “Les violations pour un build particulier”), avec diverses ventilations par type de violation, sévérité et fichier.

Enfin, vous pouvez descendre vers une classe particulière, pour afficher la liste détaillée des problèmes avec leurs emplacements dans le code source.

Mais le plugin Violations permet aussi une gestion plus proactive de la qualité du code. Vous pouvez utiliser les résultats des rapports d’analyse de la qualité du code pour influencer l’icône météorologique du tableau de bord de Jenkins. Cette icône météorologique est normalement liée au nombre de builds défaillants parmi les cinq derniers, mais Jenkins peut aussi prendre en compte d’autres facteurs, comme les résultats de la qualité du code. Afficher une icône pluvieuse ou orageuse pour un projet sur le tableau de bord est une meilleure façon de sensibiliser sur les problèmes de qualité du code que de simplement s’appuyer sur des graphiques et des rapports sur la page de la tâche de build.

Pour le configurer, vous devez revenir dans la section Report Violations dans Actions à la suite du build. Les trois premières colonnes dans Figure 9.4, “Configurer le plugin violation pour un projet free-style” montre une icône ensoleillée, une icône orageuse et une balle jaune. Celle avec l’icône de temps ensoleillé est le nombre maximum de violations tolérées pour garder l’icône ensoleillée sur la page du tableau de bord. La deuxième colonne, avec l’icône de temps orageux, est le nombre de violations qui causera l’affichage de l’icône orageuse sur le tableau de bord. Si vous avez un nombre de violations entre ces deux extrêmes, vous aurez l’une des icônes nuageuses.

Vous pouvez spécifier différentes valeurs pour différents outils. Les seuils exacts varieront entre les équipes et entre les projets, et aussi entre les outils. Par exemple, Checkstyle soulèvera généralement beaucoup plus de problèmes que FindBugs ou CPD, avec PMD quelque part entre. Vous devez ajuster les valeurs utilisées pour refléter comment ces outils travaillent avec votre code de base, et vos attentes.

Vous pouvez aller encore plus loin avec la troisième colonne (celle avec la balle jaune). Cette colonne vous permet de spécifier le nombre de violations qui déclarera le build comme instable. Souvenez-vous, lorsqu’un build devient instable, Jenkins enverra des messages de notifications, donc c’est une stratégie encore plus proactive.

Par exemple, dans Figure 9.4, “Configurer le plugin violation pour un projet free-style”, nous avons configuré le nombre minimum des violations Checkstyle à 10, ce qui signifie que l’icône du temps ensoleillé apparaîtra uniquement s’il y a au maximum 10 violations Checkstyle. S’il y en a plus de 10, le temps se dégradera progressivement, jusqu’à 200 violations marquées, où il deviendra orageux. Et s’il y a 500 violations Checkstyle ou plus, le projet sera signalé instable.

Maintenant regardez la configuration de CPD, le détecteur de code dupliqué qui vient avec PMD. Dans ce projet, nous avons adopté une politique zéro tolérance pour le code dupliqué, donc l’icône ensoleillée est spécifiée à zéro. L’icône orageuse est spécifiée à 10, donc s’il y a 10 violations de copié/collé ou plus, il sera déclaré instable.

Maintenant, sur la page du tableau de bord, le projet apparaîtra avec à la fois un une icône de temps orageux et comme instable, même s’il n’y pas d’échecs de tests (voir Figure 9.7, “Configurer le plugin de violations pour un projet free-style”). Ce build particulier est instable parce qu’il y a 16 violations CPD. En complément, si vous placez votre souris sur l’icône du temps, Jenkins affichera quelques détails supplémentaires sur comment il a calculé ce statut particulier.

Les tâches de build Maven dans Jenkins utilisent les conventions de Maven et les informations du fichier pom.xml du projet pour rendre la configuration plus facile et plus légère. Lorsque vous utilisez le plugin Violations avec une tâche de build Maven, Jenkins utilise ces conventions pour réduire la quantité de travail nécessaire pour configurer le plugin. Vous n’avez pas besoin de dire à Jenkins où trouver les rapports XML pour la plupart des outils d’analyse de code statique (par exemple, Checkstyle, PMD, FindBugs, et CPD), puisque Jenkins peut l'interpréter depuis les conventions de Maven et les configurations du plugin (voir Figure 9.8, “Configurer le plugin Violations pour un projet Maven.”). Si vous devez redéfinir ces conventions, vous pouvez choisir l’option Pattern dans la liste déroulante « XML filename pattern », et entrer le chemin comme vous pouvez le faire pour les tâches de build free-style.

Le plugin Violations fonctionne bien avec des projets multi-module Maven, mais au moment de la rédaction (de ce livre), il a besoin d’un peu de peaufinage pour obtenir de meilleurs résultats. Les tâches de build Maven comprennent la structure des projets multi-module (voir Figure 9.9, “Les tâches de build Maven de Jenkins comprennent les structures multi-modules de Maven”) ; de plus, vous pouvez descendre dans n’importe quel module et obtenir une vue détaillée des résultats de construction pour cette tâche de build.

C’est une fonctionnalité très utile, mais cela signifie que vous devez faire un peu de travail supplémentaire pour obtenir tous les avantages des plugins de violations des modules individuels. Par défaut, le plugin Violations affichera une vue agrégée des mesures de qualité de code comme celle dans Figure 9.5, “Les violations au cours du temps”. Vous pouvez aussi cliquer sur le graphique des violations, et voir les rapports détaillés de chaque module.

Cependant, pour que ceci puisse fonctionner correctement, vous devez activer le plugin Violations individuellement pour chaque module en complément du projet principal. Pour ce faire, cliquez sur le module que vous voulez configurer dans l’écran Modules, et ensuite cliquez sur le menu ‘Configurer’. Ici, vous verrez un petit groupe des options de configuration habituelles (voir Figure 9.10, “Activer le plugin Violations pour un module individuel”). Ici, il vous suffit d’activer l’option Violations, et de configurer les seuils si besoin est. Le côté positif de cela est que vous pouvez définir différentes valeurs de seuils pour des modules différents.

Une fois que cela est fait, lorsque vous cliquerez sur le graphique de violations agrégées sur la page d’accueil de la tâche de build du projet, Jenkins listera les graphiques individuels de violations pour chaque module.