Quand vous déclenchez une autre tâche de build depuis une tâche de build paramétrée, il est souvent utile de pouvoir passer les paramètres du build courant au nouveau. Supposons, par exemple, que vous ayez une application qui doit être testée sur plusieurs bases de données différentes. Comme nous l'avons vu, vous pourriez faire cela en configurant une tâche de build paramétré qui accepte la base de données cible comme un paramètre. Vous sélectionneriez une série de builds, et tous auraient besoin de ce paramètre.
Si vous essayez de faire cela en utiliser l'option conventionnelle "Construire d'autres projets" dans la section Actions Post-Build, cela ne marchera pas. En effet, vous ne pouvez pas déclencher un build paramétré de cette façon.
Toutefois, vous pouvez le faire en utilisent le plugin Jenkins Parameterized Trigger. Ce plugin vous permet de configurer vos tâches de build à la fois pour déclencher des builds paramétrés et pour passer des paramètres arbitraires à ces builds.
Une fois que vous avez installé ce plugin, vous trouverez l'option “Déclencher des builds paramétrés sur d'autres projets” dans la page de configuration de votre tâche de build (voir Figure 10.16, “Ajouter un déclencheur paramétré à une tâche de build”). Ceci vous permet de démarrer une autre tâche de build de différentes façons. En particulier, vous pouvez lancer une tâche de build ultérieure, en passant les paramètres courant à cette nouvelle tâche, ce qui est impossible à faire avec un builld paramétré normal. La meilleure façon de voir comment cela fonctionne est au travers d'un exemple.
Dans Figure 10.15, “Tâche de build paramétré pour des tests unitaires” nous
avons une tâche de build initiale. Cette tâche prend un unique paramètre,
DATABASE, qui spécifie la base de
données à utiliser pour les tests. Comme nous l'avons vu, Jenkins
demandera à l'utilisateur de saisir cette valeur à chaque fois qu'un build
sera lancé.
Supposons maintenant que nous voulons déclencher une seconde tâche de build pour exécuter des tests d'intégration plus complets une fois que la première tâche a terminé. Cependant nous avons besoin d'exécuter les tests sur la même base de données. On peut faire cela en configurant un déclencheur paramétré pour démarrer cette seconde tâche (voir Figure 10.16, “Ajouter un déclencheur paramétré à une tâche de build”).
Dans ce cas, nous passons simplement les paramètres du build
courant. Cette seconde tâche de build démarrera automatiquement après la
première, avec la valeur du paramètre DATABASE fournie par l'utilisateur. Vous pouvez
aussi configurer finement la politique de déclenchement en indiquant à
Jenkins quand le build doit être lancé. Typiquement, vous déclencheriez
seulement un build aval après que votre build ait réussi, mais avec le
plugin Parameterized Trigger vous pouvez aussi configurer les builds pour
qu'ils déclenchent même si le build est instable, ou seulement quand le build
échoue ou encore demander à ce qu'il soit déclenché quoi qu'il arrive au premier
build. Vous pouvez même configurer plusieurs déclencheurs pour la même
tâche de build.
Naturellement, la tâche de build que vous déclenchez doit être une tâche de build paramétré (comme illustré dans Figure 10.17, “La tâche de build que vous déclenchez doit aussi être une tâche paramétrée”), et vous devez transmettre tous les paramètres qu'elle requiert.
Cette fonctionnalité possède en fait des applications bien plus
larges que de simplement transmettre les paramètres du build courant. Vous
pouvez aussi déclencher une tâche de build paramétré avec un ensemble
arbitraire de paramètres, ou utiliser une combinaison de paramètres passés
au build courant, et vos propres paramètres traditionnels. Ou alors, si
vous avez beaucoup de paramètres, vous pouvez les charger à partir d'un
fichier de propriétés. Dans Figure 10.18, “Passer un paramètre prédéfini à une tâche de build
paramétré”, nous passons à la
fois les paramètres du build courant (la variable DATABASE dans ce cas), et un paramètre
additionnel appelé TARGET_PLATFORM.
