La première option vous permet de configurer un build qui se lancera à chaque fois qu'un autre build se terminera. C'est une manière facile de construire une séquence de build. Par exemple, vous pourriez configurer une tâche de build initiale qui lancera des tests unitaires et des tests d'intégration, suivie d'une autre tâche de build séparée qui lancera de l'analyse statique de code, plus gourmande en CPU. Vous remplissez simplement le nom du job précédent dans ce champ. Si la tâche de build peut être lancée par plusieurs autres tâches de build, listez simplement leurs noms ici en les séparant par des virgules. Dans ce cas là, la tâche de build sera déclenchée à chaque fois que des tâches de build présentes dans la liste se termineront.

Il y a un champ symétrique dans la section des Actions à la suite du build appelée “Construire d'autres projets”. Ce champ sera mis à jour automatiquement dans les tâches de build correspondantes en cohérence avec ce que vous aurez rempli ici. Cependant, au contraire de “Construire à la suite d'autres projets”, vous avez la possibilité de déclencher une autre tâche de build même si le build est instable (voir Figure 5.24, “Déclencher une autre tâche de build même si celle-ci est instable.”). Cela est utile par exemple si vous voulez exécuter une tâche de build sur des indicateurs de qualité du code même s'il y a des tests unitaires qui ont échoué dans la première tâche de build.

Une autre stratégie est simplement de déclencher une tâche de build à intervalle régulier. Il est important de faire remarquer qu'il ne s'agit plus d'Intégration Continue ; il s'agit simplement de builds périodiques, chose que vous pourriez tout aussi bien faire, par exemple, avec une tâche cron sous Unix. Aux débuts des builds automatisés, et toujours aujourd'hui dans beaucoup d'entreprises, les builds ne sont pas exécutés en réponse aux changements commités dans le système de contrôle de version mais seulement la nuit (build nocturne journalier). Cependant, pour être efficace, le serveur d'Intégration Continue doit apporter un retour d'information beaucoup plus rapidement qu'une seule fois par jour.

Il y a toutefois quelques cas où les tâches périodiques auront une utilité. Cela inclut les très longues tâches de build, lorsqu'un retour rapide est moins critique. Par exemple, des tests de charge et de performance intensifs qui prennent plusieurs heures à s'exécuter ou des tâches de build Sonar. Sonar est une excellente manière de conserver une vue sur vos indicateurs de qualité du code de vos projets et au fur et à mesure que le temps passe mais il ne permet de conserver qu'un seul lot de données par jour. Il n'est donc pas nécessaire d'exécuter des builds Sonar plus fréquemment que cela.

Pour toutes les tâches périodiques, Jenkins utilise une syntaxe ressemblant à celle de cron. Cette syntaxe est constituée de cinq champs séparés par des espaces blancs au format suivant :

MINUTES HEURES JOURMOIS MOIS JOURSEMAINE

Les valeurs suivantes sont possibles pour chaque champ :

Il existe également quelques raccourcis :

Généralement vous n'aurez besoin que d'une seule ligne dans ce champ mais pour des configurations de périodicité plus compliquées, vous aurez peut-être besoin de plusieurs lignes.

Comme nous avons pu le voir, les tâches de build périodiques ne sont généralement pas la meilleure stratégie pour la plupart des tâches de build d'Intégration Continue. La valeur du retour d'information est proportionnelle à la vitesse à laquelle vous recevez ce retour et il n'y a pas d'exception en ce qui concerne l'Intégration Continue. C'est pour cette raison que scruter le SCM est généralement une bien meilleure option.

La scrutation implique l'interrogation à intervalles réguliers du serveur de contrôle de version pour savoir si des changements ont été ajoutés. Si des changements ont été faits dans le code source du projet, Jenkins lance alors un build. Scruter est habituellement une opération peu coûteuse, vous pouvez donc le faire fréquemment pour vous assurer qu'un build sera lancé rapidement après tout commit de code source. Plus vous scruterez fréquemment, plus votre tâche démarrera rapidement et plus précis sera le retour d'information lié aux changements effectués dans le cas où le build échoue.

Dans Jenkins, la scrutation du SCM est très facile à configurer et utilise la même syntaxe cron précédemment présentée.

Naturellement vous aurez l'envie de scruter le SCM le plus souvent possible (par exemple en utilisant “* * * * *” pour chaque minute). Comme Jenkins n'utilise que des requêtes simples et ne lance de build que lorsque le code source a été modifié, cette approche est souvent raisonnable pour de petits projets. Cela montre cependant des limites quand il y a un grand nombre de tâches de build car cela pourrait saturer le serveur SCM et le réseau avec les requêtes dont beaucoup sont inutiles. Dans ce cas, une approche plus précise sera plus appropriée avec un déclenchement de la tâche de build directement par le SCM lorsqu'il reçoit un changement. Cette option est discutée dans Section 5.5.4, “Déclencher des builds à distance”.

Si des changements sont commités très fréquemment et dans un grand nombre de projets, cela peut causer la création d'une longue liste d'attente de tâches de build et ainsi retarder le retour d'information par la suite. Vous pouvez donc partiellement réduire la file d'attente de builds en scrutant moins régulièrement le SCM mais au prix d'un retour d'information moins précis.

Si vous utilisez CVS, scruter n'est peut être pas une bonne option. Lorsque CVS vérifie les nouveaux changements d'un projet, il vérifie chaque fichier un par un ce qui une procédure lente et fastidieuse. La meilleure solution est de migrer vers un système de contrôle de version plus moderne tel que Git ou Subversion. La deuxième meilleure solution sera de scruter à des intervalles beaucoup plus espacés (toutes les 30 minutes par exemple).

Scruter peut être une stratégie efficace pour des petits projets projects mais cela ne s'adapte pas très bien à un grand nombre de jobs. Cela utilise inutilement beaucoup de ressources réseau et il y a toujours un court délai entre le commit de nouveau code et le démarrage de la tâche de build. La stratégie sera donc de déléguer à votre système de gestion de version le déclenchement du build dans Jenkins dès qu'un changement est commité.

Il est facile de démarrer une tâche de build Jenkins à distance. Vous devez simplement invoquer une URL de la forme suivante :

http://SERVER/jenkins/job/PROJECTNAME/build

Par exemple, si mon serveur Jenkins est accessible à http://myserver:8080/jenkins, je pourrais démarrer la tâche de build gameoflife en invoquant l'URL suivante en utilisant un outil tel que wget ou curl :

$ wget http://myserver:8080/jenkins/job/gameoflife/build

L'astuce alors est de faire faire cette invocation directement par votre serveur de contrôle de version dès qu'un changement est commité. Les détails dans la manière de faire sont différent pour chaque système de contrôle de version. Dans Subversion, par exemple, vous devrez écrire un script exécuté automatiquement après la soumission de code pour faire déclencher le build. Votre script pourrait par exemple parcourir l'URL de votre dépôt, en extraire le nom du projet et ensuite effectuer une opération de wget sur l'URL correspondante à la tâche de build :

JENKINS_SERVER=http://myserver:8080/jenkins
REPOS="$1"
PROJECT=<Expression Régulière de Traitement ici>
/usr/bin/wget $JENKINS_SERVER/job/${PROJECT}/build

Cette approche ne déclenchera cependant qu'un build en particulier et se repose sur une convention de nommage qui veut que la tâche de build par défaut se base sur le nom de votre dépôt Subversion. Vous pouvez opter pour une approche plus flexible avec Subversion en utilisant directement l'API Subversion de Jenkins comme cela est démontré ici :

JENKINS_SERVER=http://myserver:8080/jenkins
REPOS="$1"
REV="$2"
UUID=`svnlook uuid $REPOS`
/usr/bin/wget \
  --header "Content-Type:text/plain;charset=UTF-8" \
  --post-data "`svnlook changed --revision $REV $REPOS`" \
  --output-document "-" \
  --timeout=2 \
  $JENKINS_SERVER/subversion/${UUID}/notifyCommit?rev=$REV

Cela déclenchera automatiquement n'importe quelle tâche de build Jenkins qui surveille ce dépôt Subversion.

Si vous avez activé la sécurité dans Jenkins, les choses peuvent devenir un peu plus compliquées. Dans le plus simple des cas (où n'importe quel utilisateur peut faire ce qu'il veut), vous n'avez qu'à activer l'option “Déclencher les builds à distance” (voir Figure 5.25, “Déclencher un build via une URL en utilisant un jeton”), et fournir une chaîne de caractères spécifique qui pourra être utilisée dans l'URL :

http://SERVER/jenkins/job/PROJECTNAME/build?token=DOIT

Cela ne fonctionnera pas si les utilisateurs ont besoin d'être authentifiés pour déclencher un build (par exemple si vous utilisez une sécurité par projet ou basée sur une matrice). Dans ce cas, vous aurez besoin de fournir un nom d'utilisateur et un mot de passe, comme montré dans l'exemple suivant :

$ wget http://scott:tiger@myserver:8080/jenkins/job/gameoflife/build

ou :

$ curl -u scott:tiger http://scott:tiger@myserver:8080/jenkins/job/gameoflife/build

Une construction ne doit pas forcément être déclenchée automatiquement. Certaines tâches de build doivent seulement être démarrées manuellement, par une intervention humaine. Par exemple, vous pourriez avoir besoin de configurer un déploiement automatique dans un environnement de test de validation (UAT), qui ne devra être démarré qu'à la demande de vos collègues de la validation (QA). Dans ce cas, laissez simplement la section Ce qui déclenche le build vide.