Gérer les paramètres Jenkins quand on est maniaque (ou flemmard)

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 !

Ce n’est pas un bug, c’est un poème

Dear Evil Tester

Un bon testeur est un testeur diabolique ; c’est ce qu’Alan Richardson met en avant dans Dear Evil Tester, un recueil de questions-réponses issues d’une chronique au sein du journal The Testing Planet. Une lecture facétieuse, qui prend le contre-pied de tous les dogmes gravitant autour du test. Alan Richardson nous invite à bousculer nos certitudes et appelle à interroger constamment le métier de testeur.

Everyone can add mutation to the testing DNA.

Cerise sur le gâteau, il nous régale d’un poème, As if it were the first day. Comme il nous a plu, nous vous en proposons une traduction libre.

Comme au premier jour

Ce n’est pas le code que le testeur affronte,
C’est lui-même qu’il met au défi, en quête
Des manières dont on il aurait pu (la honte !)
Ignorer des trous dans la raquette.

Si on laisse le temps émousser notre regard
Les bugs nous échapperont par millions et par milliards.

Alors, méfiant, je reste sur mes gardes
J’ai peur qu’un autre me chaparde
Ce petit truc sans conséquence
« Comment ne l’ai-je pas vu, ça n’a pas de sens ! »

Il n’y a rien de tel que le passé : l’expérience du temps est une illusion
Il n’y a rien de tel que le présent, et j’ai la solution.

Je reste dans l’instant, mais pas dans le plan-plan
Je reste alerte, yeux grands ouverts et armé jusqu’aux dents
De mes talents, de mes modèles et mes outils (la fine équipe !)
L’appli ne peut pas gagner. C’est mon seul principe.

Je ne reteste pas. Je teste, je teste et je teste encore,
Comme au premier jour, aussi bien et aussi fort.

Bonne lecture, et n’hésitez pas à poster en commentaire ce que vous avez pensé de ce livre !

Vous pouvez même télécharger le poème au format image comme ci-dessous s’il vous prend l’envie de l’afficher dans votre bureau…

Une chanson sur le test logiciel ?

Ceci est une mise à jour du 27 mai 2019.

Dans le même registre, nous venons de découvrir sur le site Test Automation University une chanson sur la testeuse Angie Jones. Bonne écoute, et n’hésitez pas à nous faire part de toute autre œuvre lyrique sur notre beau métier !

Vous reprendrez bien un peu d’humour testeur 🙂

Les 7 principes généraux du test en illustrations

3 maladies de l’automatisation des tests

Le kit de secours métaphorique du testeur agile