La première section que vous voyez lorsque vous créez un job de type free-style contient les informations générales du projet comme son nom unique ou sa description ainsi que d'autres indiquant comment et où la tâche de build doit être exécutée (voir Figure 5.2, “Créer une nouvelle tâche de build”).

Le nom du projet peut être n'importe lequel mais il est bon de noter qu'il sera utilisé comme repertoire du projet et dans les URLs du job. J'évite donc généralement d'utiliser des noms avec des espaces. La description du projet apparaîtra sur la page de démarrage du projet — utilisez la pour donner une idée générale sur le but de la tâche de build et son contexte. Les tags HTML y sont acceptés.

Les autres options sont plus techniques et nous reviendrons sur quelques unes plus en détails dans la suite de ce guide.

Un des aspects importants est la manière dont vous allez gérer l'historique de vos builds. Les tâches de build peuvent consommer beaucoup d'espace disque particulièrement si vous archivez les artefacts de vos builds (les fichiers binaires tels que JARs, WARs, TARs, etc. générés par votre tâche de build). Même sans artefacts, garder un enregistrement pour chaque tâche de build consomme de la mémoire et de l'espace disque supplémentaire et cela n'est peut être pas justifié selon la nature de votre tâche de build. Par exemple, pour un job de qualimétrie générant des rapports sur l'analyse statique et la couverture de votre code dans le temps, vous pourriez vouloir garder une trace de vos builds pendant toute la durée du projet. Cependant, pour une tâche de build qui déploie automatiquement une application sur un serveur de test, garder un historique et les artefacts pour la postérité est peut être beaucoup moins important.

L'option de suppression des anciens builds vous permet de limiter le nombre de builds conservés dans l'historique. Vous pouvez aussi bien demander à Jenkins de ne garder que les builds récents (Jenkins supprimera les builds après un certain nombre de jours) ou ne garder pas plus qu'un nombre déterminé de builds. Si un build en particulier a une valeur sentimentale pour vous, vous pouvez toujours demander à Jenkins de le conserver à tout jamais en utilisant le bouton de conservation sans limite de temps sur la page de détails du build (voir Figure 5.3, “Conserver un build sans limite de temps”). Notez que ce bouton n'apparaitra que si vous avez demandé à Jenkins de supprimer les anciens builds.

En plus de cela, Jenkins ne supprimera jamais le dernier build stable qui s'est terminé avec succès, peu importe son ancienneté. Par exemple, si vous limitez Jenkins pour ne conserver que les vingt derniers builds et que votre dernier build qui s'est terminé avec succès s'est exécuté trente builds plus tôt, Jenkins le conservera en plus des vingt derniers builds échoués.

Vous avez aussi la possibilité de désactiver une tâche. Une tâche désactivée ne sera pas exécutée tant que vous ne l'aurez pas réactivée. Utiliser cette option lorsque vous venez de créer votre job est cependant assez rare. D'un autre côté, cette option est souvent utile lorsque vous devez suspendre temporairement une tâche pendant une maintenance ou une grande refactorisation du projet et plus généralement lorsqu'une notification d'echec de la tâche de build ne sera pas utile à l'équipe.

Les options avancées du projet contiennent, comme l'indique le nom de cette section, des options de configuration moins courantes. Vous devrez cliquer sur le bouton Avancé pour les faire apparaitre. (voir Figure 5.4, “Pour afficher les options avancées, vous devez cliquer sur le bouton Avancé...”).

L'option période d'attente dans la configuration du job vous permet simplement d'outrepasser la période d'attente définie globalement dans la configuration du système de Jenkins (voir Section 4.3, “Configurer l'environnement système”). Cette option est principalement utilisée pour les systèmes de gestion de version qui ne supportent pas les commits atomiques, comme par exemple CVS, mais également dans les équipes où les développeurs ont pour habitude de diviser le commit de leur travail en plusieurs petites contributions.

L'option “Empêcher le build quand un projet en amont est en cours de build” est utile lorsque plusieurs projets liés sont affectés par un seul commit mais qu'ils doivent être construits dans un ordre spécifique. Si vous activez cette option, Jenkins attendra que toutes les tâches de build en amont (voir Section 5.5, “Déclencheurs de build”) soient terminées avant de démarrer le build.

Par exemple, lorsque vous livrez une nouvelle version d'un projet Apache Maven multimodule, la mise à jour du numéro de version se fera dans plusieurs, voir l'ensemble, des modules du projet. Supposons que nous ayons ajouté une application web au projet Game of Life que nous avons utilisé dans le Chapter 2, Vos premiers pas avec Jenkins, et que nous l'ayons ajouté sous la forme d'un projet Apache Maven séparé. Lorsque nous livrons une nouvelle version de ce projet, aussi bien le numéro de version du core que celui de l'application web seront mis à jour (voir Figure 5.5, “L'option “Empêcher le build quand un projet en aval est en cours de build” est utile quand un simple commit affecte plusieurs projets dépendants les uns des autres.”). Avant de pouvoir construire l'application web, nous devons construire une nouvelle version du module core de Game of Life. Cependant, si vous avez des tâches de build free-style séparées pour chaque module, les tâches de build de l'application web et du core devraient démarrer simultanément. Le build de l'application web échouera si le build du core n'a pas produit de nouvelle version du module du core, même s'il n'y a pas de test échoué.

Pour éviter ce problème, vous pourriez configurer la tâche de build de l'application web pour démarrer seulement si le build du core s'est terminé avec succès. Cependant, cela signifie que l'application web ne serait jamais construite si des changements étaient effectués uniquement pour celle-ci et non pour le module core. Une meilleure approche est alors d'utiliser l'option “Construire à la suite d'autres projets (projets en amont)”. Dans ce cas, lorsqu'un numéro de version a été mis à jour dans le contrôle de version, Jenkins programmera les deux builds pour leur exécution. Il attendra cependant que le build du module core se soit terminé pour démarrer le build de l'application web.

Vous pouvez également surcharger l'espace de travail par défaut utilisé par Jenkins pour y tirer le code source et construire votre projet. De manière générale, Jenkins créera un espace de travail spécifique pour votre projet accessible dans le répertoire de la tâche de build de votre projet (voir Section 3.13, “What’s in the Jenkins Home Directory”). Cela fonctionne dans presque tous les cas. Il y a cependant des cas dans lesquels vous pourriez avoir besoin de forcer Jenkins à utiliser un espace de travail différent grâce à cette option. Un exemple serait le cas où vous auriez besoin de construire plusieurs tâches de build dans un même espace de travail. Vous pouvez définir un répertoire de travail différent en cochant l'option “Utiliser un répertoire de travail spécifique” et en spécifiant le chemin vous même. Ce chemin peut aussi bien être absolu ou relatif au répertoire de base de Jenkins.

Nous verrons d'autres options avancées qui apparaissent dans cette section plus loin dans ce livre.