Problème : des paramètres Jenkins interdépendants
Il n’est pas rare, quand on construit un build Jenkins avec des paramètres, que ceux-ci dépendent les uns des autres.
Exemple de configuration
Vous avez un paramètre de choix « Type de plat » avec comme valeurs possibles « Entrée », « Plat », « Dessert » et « Après-dessert » (un après-dessert est toujours le bienvenu).
Vous avez un autre paramètre de choix « Plat » avec comme valeurs possibles « Champignons à la grecque », « Spaghettis au roquefort », « Brownie » et « Salade de kiwis ».
Vous avez en tête un certain nombre de règles.
- Les champignons à la grecque peuvent être commandés en tant qu’entrée ou plat principal
- Les spaghettis au roquefort sont un plat
- Il est possible de commander un brownie en dessert, mais pas en après-dessert, car ce ne serait pas raisonnable
- La salade de kiwis peut être commandée en dessert ou en après-dessert.
Pourquoi cette configuration pose-t-elle problème ?
Possibilité 1 : vous êtes prudent (ou maniaque) et aimeriez interdire certaines combinaisons incohérentes.
Possibilité 2 : vous êtes flemmard et aimeriez gagner un peu de temps au moment de lancer un build.
Heureusement que la vie est bien faite et qu’il existe un plugin rien que pour vous.
Solution : Active Choices, un plugin Jenkins pour créer des conditions entre paramètres
Autrefois appelé Uno-Choice, le plugin Active Choice est gratuit et disponible directement depuis le gestionnaire de plugins de Jenkins.
Exemple d’utilisation d’Active Choices
Pour le cas énoncé, nous allons ajouter au job un paramètre de choix. Veillons simplement à ce que son nom soit en un seul mot, en écrivant « Type de plat » en camelcase. C’est important pour pouvoir ensuite utiliser ce nom comme une variable.
Maintenant, au lieu de créer un autre paramètre de choix classique, ajoutons un paramètre de type « Active Choices Reactive Parameter ».
Il faut maintenant cocher la case « Groovy Script », qui va nous permettre d’écrire nos règles. Ici, le script correspondant est le suivant :
if (TypeDePlat.equals("Entrée")) {
return ["Champignons à la grecque"]
} else if (TypeDePlat.equals("Plat de résistance")) {
return ["Champignons à la grecque", "Spaghettis au roquefort"]
} else if (TypeDePlat.equals("Dessert")) {
return ["Brownie", "Salade de kiwis"]
} else if (TypeDePlat.equals("Après-dessert")) {
return ["Salade de kiwis"]
} else {
return ["Des petits cailloux ramassés dans l'allée"]
}
On indique une valeur par défaut dans le Fallback Script (par prudence, veiller à ce qu’elle soit cohérente avec la première valeur du paramètre de choix standard) :
return ["Champignons à la grecque"]
Maintenant, il faut simplement préciser à quel paramètre on se réfère.
Après sauvegarde de la configuration, lorsqu’on lance un build avec des paramètres, la liste déroulante des plats se met à jour en fonction de la valeur choisie dans la liste des types de plats. Pratique !
Ordre d’apparition des paramètres
Si vous êtes vraiment maniaque, vous remarquerez que les paramètres s’affichent dans la liste déroulante dans le même ordre que celui du script, et que par défaut, c’est le premier élément de la liste qui sera choisi.
Pour modifier cette valeur sans changer l’ordre alphabétique, au lieu de mettre l’élément voulu au début de la liste, il suffit de lui apposer « :selected« , comme ci-après :
return ["Champignons à la grecque", "Spaghettis au roquefort:selected"]
Conclusion
Le plugin offre de nombreux paramétrages possibles ; prenez le temps de les essayer, ça en vaut la peine !
Vous aimerez peut-être…
SonarQube met son grain de sel dans Gitlab !
Cas d’usage : JSoup et Gatling pour repérer les liens morts
L’automatisation des tests, c’est votre dada ? Voilà une ressource qui en parle en long, en large et en travers !
