L'historique des builds prend de l'espace disque. De plus, Jenkins analyse les builds précédents lorsqu'il charge la configuration d'un projet. Ainsi, le chargement d'une tâche avec un millier de builds archivés prendra bien plus de temps qu'une tâche n'en n'ayant que 50. Si vous avez un gros serveur Jenkins avec des dizaines ou des milliers de tâches, le temps total est proportionellement multiplié.
La façon la plus simple de plafonner l'utilisation de l'espace disque est probablement de limiter le nombre de builds qu'un projet conserve dans son historique. Cela se configure en cochant la case "Supprimer les anciens builds" en haut de la page de configuration d'un projet (voir Figure 13.1, “Suppression des anciens builds” ). Si vous dites à Jenkins de ne garder que les 20 derniers builds, il commencera à effacer les plus vieux builds une fois ce nombre atteint. Vous pouvez limiter le nombre d'anciens builds conservés par un nombre de builds ou par date (par exemple les builds de moins de 30 jours). Jenkins fait cela intelligemment: il gardera toujours le dernier build réussi au sein de son historique, ainsi vous ne perdrez jamais votre dernier build réussi.
Le problème avec la suppresion des anciens builds est que vous perdez l'historique des builds par la même occasion. Pourtant, Jenkins utilise cet historique pour réaliser différents graphiques sur les résultats des tests et les métriques de build. Limiter le nombre de build conservé à 20, par exemple, implique que Jenkins affichera des graphiques contenant seulement 20 points. Cela peut être un peu limité. Cette sorte d'information peut être très utile aux développeurs. Il est souvent intéressant de pouvoir afficher l'évolution des métriques sur l'ensemble de la vie du projet, et pas seulement sur les 2 dernières semaines.
Heuresement, Jenkins a un mécanisme à même de rendre les développeurs et les administraturs systèmes heureux. En général, les éléments prenant le plus de place sont les artefacts de build : fichiers JAR, WAR et ainsi de suite. L'historique de build en elle-même est principalement constituée de fichiers de log XML, qui ne prennent pas trop de place. Si vous cliquez sur le button "Avancé...", Jenkins vous offre la possibilité de supprimer les artefacts mais pas les données du build. Dans Figure 13.2, “Supprimer les anciens builds — options avancées” , par exemple, nous avons configuré Jenkins pour qu'il garde les artefacts 7 jours au maximum. Cette option est vraiment pratique si vous avez besoin de limiter l'utilisation du disque tout en désirant fournir l'ensemble des métriques pour les équipes de développement.
N'hésitez pas à être drastique, en gardant un nombre maximal d'artefact assez faible. Souvenez vous que Jenkins gardera toujours le dernier build stable et le dernier réussi, quelque soit sa configuration. Ainsi, vous aurez toujours au moins le dernier build réussi (à moins bien sûr qu'il n'y ait pas encore eu de build réussi). Jenkins offre également de marquer un build particulier à "Conserver ce build sans limite de temps", afin que certains builds importants ne puissent être supprimés automatiquement.
Le plugin Disk Usage est un des plus utiles pour un administrateur Jenkins. Ce plugin conserve et reporte l'espace disque utilisé par vos projets. Il vous permet de repérer et corriger les projets qui utilisent trop d'espace.
Vous pouvez installer le plugin Disk Usage de la façon habituelle, depuis l'écran "Gestion des plugins". Après installation du plugin et redémarrage de Jenkins, le plugin Disk Usage enregistre la quantité d'espace disque utilisée par chaque projet. Il ajoute également un lien "Disk usage" sur la page "Administrer Jenkins". Ce lien vous permet d'afficher la quantité totale d'espace utilisé par vos projets (voir Figure 13.3, “Voir l'utilisation d'espace disque” ).
La liste est triée par utilisation totale d'espace disque, ainsi les projets utilisant le plus d'espace apparaissent en haut. La liste fournit deux valeurs par projet. La colonne "Builds" indique l'espace disque total utilisé par l'historique des builds, tandis que la colonne "Workspace" est l'espace disque utilisé pour construire le projet. Pour les projets en cours, l'espace utilisé par l'espace de travail tend à être relativement stable, tandis que la valeur pour l'historique des builds croit au cours du temps, parfois à une vitesse excessivement rapide, à moins que vous ne fassiez quelque chose. Vous pouvez garder sous contrôle l'espace disque utilisé par l'historique d'un projet en limitant le nombre de builds conservés et en faisant attention à quels artefacts sont conservés.
Pour se faire une idée sur la vitesse à laquelle l'espace disque est utilisé, vous pouvez aussi afficher l'espace disque utilisé par chaque projet au cours du temps. Pour faire cela, vous devez configurer le plugin sur la page "Configurer le système" (voir Figure 13.4, “Affichage de l'utilisation disque d'un projet” ).
Cela va enregistrer et afficher combien d'espace disque vos projets consomment au cours du temps. Le plugin "Disk Usage" affiche un graphique de l'utlisation du disque au cours du temps (voir Figure 13.5, “Affichage de l'espace disque d'un projet au cours du temps ” ) qui donne un bon aperçu de la vitesse à laquelle votre projet consomme l'espace disque, ou au contraire si l'espace utilisé est stable au cours du temps.
Si vous utilisez les tâches de build Maven, il y a des détails supplémentaires que vous devriez connaître. Dans Jenkins, les tâches de build Maven archivent automatiquement, par défaut, les artefacts du build. Cela peut être différent de vos attentes.
Le problème est que ces artefacts SNAPSHOT prennent de la place, beaucoup même. Sur un projet actif, Jenkins est susceptible de réaliser plusieurs builds par heure. Stocker de façon permanente chacun des fichiers JAR générés pour chaque build peut être vraiment couteux. Le problème s'amplifie si vous avez des projets multimodules. En effet, Jenkins archive les artefacts générés pour chaque module.
En fait, si vous avez besoin d'archiver vos artefacts SNAPSHOT Maven, il est probablement plus avisé de les déployer directement dans votre gestionnaire de dépôt local. Nexus Pro, par exemple, peut être configuré pour faire cela. Artifactory peut être configuré pour supprimer les vieux artefacts SNAPSHOT.
Heuresement, vous pouvez configurer Jenkins pour réaliser cela. Allez dans la section "Buid" de l'écran de configuration de votre tâche et cliquez sur le bouton "Avancé...". Des champs supplémentaires sont alors affichés, comme montré dans Figure 13.6, “Tâches de build Maven—options avancées” .
Si vous cochez l'option “Désactive l'archivage automatique des artefacts”, Jenkins ne stockera pas les fichiers Jar généré par les builds de votre projet. C'est une bonne façon de rendre heureux votre administrateur système.
Notez que parfois vous avez vraiment besoin d'archiver les artefacts Maven. Par exemple, cela s'avère souvent utiles quand vous implémentez un séquenceur de build (voir Section 10.7, “Pipelines de build et promotions” ). Dans ce cas, vous pouvez toujours choisir, manuellement, les artefacts nécessaires, et alors utiliser l'option "Supprimer les anciens builds" pour définir la durée de conservation.