Jenkins - passer des variables entre les emplois?
J'ai deux emplois dans Jenkins, qui ont tous deux besoin du même paramètre.
Comment puis-je exécuter le premier travail avec un paramètre de sorte que, lorsqu'il déclenche le deuxième travail, le même paramètre soit utilisé?
Vous pouvez utiliser Parameterized Trigger Plugin qui vous permettra de passer des paramètres d’une tâche à une autre.
Vous devez également ajouter ce paramètre que vous avez transmis d’amont en aval.
1.Post-Build Actions> Sélectionnez ”Déclencheur paramétré sur d'autres projets”
2. Entrez la variable d'environnement avec value.Value peut également être Jenkins Build Parameters.
Les étapes détaillées peuvent être vues ici: -
J'espère que c'est utile :)
La réponse acceptée ici ne fonctionne pas pour mon cas d'utilisation. Je devais être capable de créer dynamiquement des paramètres dans un travail et de les transmettre à un autre. Comme Mark McKenna le mentionne, il n’ya apparemment aucun moyen d’exporter une variable d’une étape de construction Shell vers les actions post-construction.
J'ai réussi à contourner le problème en utilisant Parameterized Trigger Plugin en écrivant les valeurs dans un fichier et en utilisant ce fichier comme paramètres à importer via "Ajouter une action post-construction" -> "Déclencheur de génération paramétrée ..." puis en sélectionnant " Ajouter des paramètres '->' Paramètres du fichier de propriétés '.
Je pense que la réponse ci-dessus nécessite une mise à jour:
J'essayais de créer un répertoire dynamique pour stocker mes artefacts de construction en amont; je voulais donc transmettre mon numéro de construction de travail en amont à un travail en aval. J'ai essayé les étapes ci-dessus, mais je n'ai pas réussi à le faire fonctionner. Voici comment cela a fonctionné:
- J'ai copié les artefacts de mon travail actuel à l'aide du plug-in de copie d'artefacts.
- Dans l'action post-construction du travail en amont, j'ai ajouté la variable du type "SOURCE_BUILD_NUMBER = $ {BUILD_NUMBER}" et l'ai configurée pour déclencher le travail en aval.
- Tout a fonctionné sauf que mon travail en aval n'a pas pu obtenir que $ SOURCE_BUILD_NUMBER crée le répertoire.
- J'ai donc découvert que pour utiliser cette variable, je devais définir la même variable dans le travail en aval en tant que variable de paramètre, comme dans l'image ci-dessous:
En effet, la nouvelle version de jenkins vous oblige également à définir la variable dans le travail en aval. J'espère que c'est utile.
(pour les autres googlers)
Si vous construisez un pipeline sérieux avec le plugin Build Flow , vous pouvez transmettre des paramètres entre les travaux avec le DSL comme suit:
Supposant un paramètre de chaîne disponible "CVS_TAG", afin de le transmettre à d'autres travaux:
build("pipeline_begin", CVS_TAG: params['CVS_TAG'])
parallel (
// will be scheduled in parallel.
{ build("pipeline_static_analysis", CVS_TAG: params['CVS_TAG']) },
{ build("pipeline_nonreg", CVS_TAG: params['CVS_TAG']) }
)
// will be triggered after previous jobs complete
build("pipeline_end", CVS_TAG: params['CVS_TAG'])
Astuce pour afficher les variables/paramètres disponibles:
// output values
out.println '------------------------------------'
out.println 'Triggered Parameters Map:'
out.println params
out.println '------------------------------------'
out.println 'Build Object Properties:'
build.properties.each { out.println "$it.key -> $it.value" }
out.println '------------------------------------'
Ajoutez simplement ma réponse à celle de Nigel Kirby car je ne peux pas encore commenter:
Afin de transmettre un paramètre créé dynamiquement, vous pouvez également exporter la variable dans la mosaïque "Exécuter Shell", puis la transmettre via "Déclencheur paramétré pour d'autres projets" => "Paramètres prédéfinis" => donner "YOUR_VAR = $ YOUR_VAR". Mon équipe utilise cette fonctionnalité pour passer la version du package npm, du travail de construction aux travaux de déploiement.
UPDATE: ci-dessus ne fonctionne que pour les paramètres injectés Jenkins, le paramètre créé à partir de Shell doit toujours utiliser la même méthode. par exemple. echo YOUR_VAR = $ {YOUR_VAR}> variable.properties et transmettez ce fichier en aval
Vous pouvez utiliser Hudson Groovy builder pour le faire.
Premier emploi en cours
Deuxième emploi en cours
J'ai rencontré le même problème lorsque j'ai dû passer une version pom à un travail Rundeck en aval.
Ce que j'ai fait, c'est utiliser l'injection de paramètres via un fichier de propriétés en tant que tel:
1) Création de propriétés dans un fichier de propriétés via Shell:
Construire des actions:
- Exécuter un script shell
- Injecter des variables d'environnement
E.g: définition des propriétés
2) Passage des propriétés définies au travail en aval: Actions après construction:
- Déclencheur paramétré sur un autre projet
- Ajouter des paramètres: paramètres de construction actuels
- Ajouter des paramètres: paramètres prédéfinis
E.g: envoi de propriétés
3) Il était alors possible d'utiliser $ POM_VERSION en tant que tel dans le travail Rundeck en aval.
/!\Jenkins Version: 1.636
/!\Pour une raison quelconque lors de la création de la construction déclenchée, il était nécessaire d’ajouter l’option 'Paramètres actuels de la construction' pour transmettre les propriétés.
En lisant les réponses, je ne vois pas d’autre option que j’aime bien, donc je l’offrirai aussi. J'adore le paramétrage des emplois, mais il ne s'adapte pas toujours bien. Si vous avez des travaux qui ne sont pas directement en aval du premier travail mais plus loin dans le pipeline, vous ne voulez pas vraiment paramétrer chaque travail du pipeline afin de pouvoir passer les paramètres à fond. Ou bien, si vous utilisez un grand nombre de paramètres utilisés par divers autres travaux (en particulier ceux qui ne sont pas nécessairement liés à un travail parent ou maître), là encore, le paramétrage ne fonctionne pas.
Dans ces cas, je préfère exporter les valeurs dans un fichier de propriétés, puis l'injecter dans le travail dont j'ai besoin à l'aide du plugin EnvInject . Cela peut être fait de manière dynamique, ce qui est un autre moyen de résoudre le problème à partir d'une autre réponse ci-dessus où des tâches paramétrées étaient encore utilisées. Cette solution évolue très bien dans de nombreux scénarios.
Voir ma réponse dans cet autre post:
A travaillé pour moi (le paramètre doit être spécifié dans les deux travaux, pas seulement dans le travail parent)