4.3. Configurer l'environnement système

La page d'administration la plus importante de Jenkins est l'écran Configurer le système (Figure 4.2, “Configuration du système dans Jenkins”). Ici, vous paramétrez la plupart des outils fondamentaux dont Jenkins a besoin pour son travail quotidien. L'écran par défaut contient un certain nombre de sections, chacune concernant un domaine différent ou un outil externe. De plus, quand vous installez des plugins, leur configuration système globale est aussi souvent effectuée dans cet écran.

Configuration du système dans Jenkins

Figure 4.2. Configuration du système dans Jenkins


L'écran Configurer le système vous permet de définir les paramètres globaux pour votre installation Jenkins, et aussi pour vos outils externes nécessaires au processus de build. La première partie de cet écran permet de définir certains paramètres de niveau système.

Le répertoire de travail de Jenkins est indiqué, pour référence. De cette façon, vous pouvez vérifier d'un coup d'œil que vous travaillez avec le répertoire de travail auquel vous vous attendez. Rappelez-vous, vous pouvez changer ce répertoire en positionnant la variable d'environnement JENKINS_HOME dans votre environnement (voir Section 3.4, “Le répertoire de travail de Jenkins”).

Le champ Message du système sert à plusieurs choses. Ce texte est affiché en haut de votre page d'accueil Jenkins. Vous pouvez utiliser des balises HTML, c'est donc un moyen simple de personnaliser votre serveur de build en incluant le nom de votre serveur et un petit laïus sur son rôle. Vous pouvez aussi l'utiliser pour afficher des messages pour tous les utilisateurs, pour annoncer par exemple des indisponibilités du système, etc.

La Période d'attente est utile pour les outils de gestion de sources comme CVS qui committent les fichiers un par un, au lieu de les grouper ensemble en une seule transaction atomique. Normalement, Jenkins déclenchera un build dès qu'il détectera un changement dans le dépôt de sources. Toutefois, cela ne convient pas à tous les environnements. Si vous utilisez un outil comme CVS, vous ne devriez pas lancer un build dès que le premier changement arrive, parce que le dépôt sera dans un état inconsistant tant que tous les changements n'auront pas été committés. Vous pouvez utiliser le champ Période d'attente pour éviter des problèmes de ce genre. Si vous mettez une valeur à cet endroit, Jenkins attendra qu'aucun changement n'ait été détecté pendant le nombre spécifié de secondes avant de déclencher le build. Ceci permet de s'assurer que tous les changements ont été committés et que le dépôt est dans un état stable avant de démarrer le build.

Pour les systèmes de gestion de version modernes, comme Subversion, Git ou Mercurial, les commits sont atomiques. Cela signifie que des changements dans plusieurs fichiers sont soumis au dépôt comme unité simple, et le code source sur le dépôt est garanti d'être à tout moment dans un état stable. Toutefois, certaines équipes utilisent encore une approche où un changement logique est livré en plusieurs commits. Dans ce cas, vous pouvez utiliser la Période d'attente pour vous assurer que le build utilise toujours une version stable de code source.

La valeur de Période d'attente spécifiée est la valeur par défaut au niveau système — si nécessaire, vous pouvez redéfinir cette valeur individuellement pour chaque projet.

Vous pouvez aussi gérer les comptes utilisateurs et les droits ici. Par défaut, Jenkins laisse n'importe quel utilisateur faire ce qu'il souhaite. Si vous souhaitez une approche plus restrictive, vous devrez activer la sécurité de Jenkins en sélectionnant le champ Activer la sécurité. Il y a plusieurs façons de gérer cela, nous regarderons cet aspect de Jenkins plus tard (voir Chapter 7, Sécuriser Jenkins).