En plus de configurer les comptes utilisateurs et leurs droits d'accès, il peut être utile de garder des actions de chaque utilisateur : en d'autres termes, qui a fait quoi à votre configuration serveur. Ce type de traçage est même requis dans certaines organisations.

Il y a deux plugins Jenkins qui peuvent vous aider à accomplir cela. Le plugin Audit Trail conserve un enregistrement des changements utilisateur dans un fichier de log spécial. Et le plugin JobConfigHistory vous permet de garder des copies de versions précédentes des diverses configurations de tâches et du système que Jenkins utilise.

Le plugin Audit Trail garde une trace des principales actions utilisateur dans un ensemble de fichiers de logs tournants. Pour mettre cela en place, allez sur la page Gérer les plugins et sélectionnez le plugin Audit Trail dans la liste des plugins disponibles. Ensuite, comme d'habitude, cliquez sur Installer et redémarrez Jenkins une fois que le plugin a été téléchargé.

La configuration de l'audit trail s'effectue dans la section Audit Trail de l'écran de configuration principal de Jenkins (voir Figure 7.28, “Configurer le plugin Audit Trail”). Le champ le plus important est l'emplacement des logs, qui indique où se trouve le répertoire dans lequel les logs doivent être écrits. L'audit trail est conçu pour produire des logs de style système, qui sont souvent placés dans un répertoire système comme /var/log. Vous pouvez aussi configurer le nombre de fichiers de logs à maintenir, et la taille maximale (approximative) de chaque fichier. L'option la plus simple est de fournir un chemin absolu (comme /var/log/hudson.log), auquel cas Jenkins écrira dans des fichiers de logs avec des noms comme /var/log/hudson.log.1, /var/log/hudson.log.2, et ainsi de suite. Bien sûr, vous devez vous assurer que l'utilisateur exécutant votre instance Jenkins peut écrire dans ce répertoire.

Vous pouvez aussi utiliser le format défini dans la classe de l'API de logging Java FileHandler pour plus de contrôle sur les fichiers de log générés. Dans ce format, vous pouvez insérer des variables telles que %h, pour le répertoire racine de l'utilisateur courant, et %t, pour le répertoire temporaire du système, afin de construire un chemin de fichier plus dynamique.

Par défaut, les détails enregistrés dans les logs d'audit sont assez légers — ils enregistrement effectivement les actions clés effectuées, comme la création, la modification ou la suppression de configurations de tâches ou de vues, ainsi que l'utilisateur qui a effectué ces actions. Le log montre aussi comment les tâches individuelles ont été démarrées. Voici un extrait du log par défaut :

Dec 27, 2010 9:16:08 AM /job/game-of-life/configSubmit by johnsmart
Dec 27, 2010 9:16:42 AM /view/All/createItem by johnsmart
Dec 27, 2010 9:16:57 AM /job/game-of-life-prod-deployment/doDelete by johnsmart
Dec 27, 2010 9:24:38 AM job/game-of-life/ #177 Started by user johnsmart
Dec 27, 2010 9:25:57 AM job/game-of-life-acceptance-tests/ #107 Started by upstream 
    project "game-of-life" build number 177
Dec 27, 2010 9:25:58 AM job/game-of-life-functional-tests/ #7 Started by upstream 
    project "game-of-life" build number 177
Dec 27, 2010 9:28:15 AM /configSubmit by johnsmart

L'audit trail est certainement utile, particulièrement avec une perspective d'administration système. Toutefois, cela ne produit pas d'information à propos des changements exacts qui ont été faits à la configuration Jenkins. Néanmoins, une des raisons les plus importantes pour garder des traces d'actions utilisateurs dans Jenkins est de savoir quels changements ont été faits aux configurations de tâches de build. Quand quelque chose se passe mal, il peut être utile de savoir quels changements ont été faits et être donc capables de les défaire. Le plugin JobConfigHistory vous permet justement de faire cela.

Le plugin JobConfigHistory est un outil puissant vous permettant de conserver l'historique complet des changements faits à la fois sur les tâches et fichiers de configuration système. Vous l'installez depuis le gestionnaire de plugin de la façon habituelle. Une fois installé, vous pouvez régler finement la configuration de l'historique des tâches dans l'écran Administrer Jenkins (voir Figure 7.29, “Mettre en place l'historique des configurations de tâches”).

Ici, vous pouvez configurer un bon nombre d'options utiles non standard. En particulier, vous devriez spécifier un répertoire où Jenkins peut stocker l'historique de configuration, dans le champ "Répertoire racine de l'historique”. C'est le répertoire dans lequel Jenkins stockera un enregistrement des changements à la fois liés au système et aux configuration de tâches. Cela peut être à la fois un répertoire absolu (comme /var/hudson/history), ou un répertoire relatif, calculé à partir de la racine du répertoire de Jenkins (voir Section 3.4, “Le répertoire de travail de Jenkins”). Si vous ne faites pas cela, l'historique de configuration des tâches sera stocké dans les tâches elles-mêmes, et tout sera perdu si vous supprimez une tâche.

Il y a un certain nombre d'autres options utiles dans la section Avancé. La case à cocher “Sauver les changements de configuration système” vous permet de garder la trace de mise à jour de configuration de niveau système, et non pas seulement de celles spécifiques aux tâches. Et la case à cocher “Ne pas sauver d'historique dupliqué” vous permet d'éviter d'avoir des enregistrements de configuration si aucun changement réel n'a été effectué. Sinon, une nouvelle version du fichier de configuration sera enregistrée, même si vous avez seulement appuyé sur le bouton Sauver sans faire aucun changement. Jenkins peut aussi provoquer cela en interne - par exemple, le paramétrage de la configuration système est entièrement sauvé à chaque fois que la page principale de configuration est sauvée, même si aucune modification n'a été faite.

Une fois que vous avez mis ce plugin en place, vous pouvez accéder à l'historique pour le serveur complet, incluant les mises à jour de configuration système, aussi bien qu'aux changements effectués à la configuration de chaque projet. Dans les deux cas, vous pouvez voir ces changements en cliquant sur l'icône Job Config History sur la droite de l'écran. Cliquer sur cette icône affichera une vue de tout votre historique de configuration, incluant les changements de tâches et les changements de niveau système (voir Figure 7.30, “Présentation de l'historique de configuration des tâches”).

Si vous cliquez sur un changement de niveau système (indiqué par le suffixe “(system)” dans la liste), Jenkins vous emmène vers un écran listant toutes les versions de ce fichier, et vous permet de voir les différences entre les versions (voir Figure 7.31, “Voir les différences dans l'historique de configuration des tâches”). Les différences sont affichées sous la forme de fichiers diff, ce qui n'est pas particulièrement lisible en soi. Toutefois, pour de petits changements, le format XML lisible de Jenkins rend cela suffisant pour comprendre le changement qui a été effectué.

Le plugin JobConfigHistory est un outil puissant. Toutefois, à l'écriture de ces lignes, il a ses limites. Comme mentionné, le plugin affiche uniquement les différences au format diff brut, et vous ne pouvez pas restaurer une version précédente d'un fichier de configuration (faire cela hors contexte pourrait être dangereux dans certaines circonstances, particulièrement pour les fichiers de configuration système). Cependant, il donne un aperçu très clair des changements ayant été effectués, à la fois sur vos tâches de build et sur votre configuration système.