Jenkins - passer des variables entre les travaux?


87

J'ai deux emplois à 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é?


Nous pouvons utiliser de nombreuses façons: une meilleure façon est d'utiliser les paramètres de travail actuels, ou d'utiliser des paramètres prédéfinis dans le travail en aval de déclenchement
ksr

1
Ce titre est si déroutant. Comment est-ce "passer des variables entre les travaux?". La réponse acceptée est également un plugin. Fantaisie ça!
Rakib

Réponses:


73

Vous pouvez utiliser le plugin de déclenchement paramétré qui vous permettra de passer des paramètres d'une tâche à une autre.

Vous devez également ajouter ce paramètre que vous avez passé de l'amont à l'aval.


10
Salut désolé de sonner comme un noob, mais est-ce que ça va si quelqu'un peut éditer ceci avec des détails sur la façon de le faire avec le plugin de déclenchement paramétré?
Fadi

10
Note latérale: il ne semble pas que les variables d'environnement exportées créées dans les sections de script bash soient éligibles pour la substitution dans les paramètres de sortie (par exemple, 'export VERSION' ne fera pas prendre la valeur correcte à 'UPSTREAM_VERSION = $ VERSION'; il obtient juste '$ VERSION' à la place).
Mark McKenna

21
Cette réponse est insuffisante
tarabyte

6
Je suis d'accord qu'il devrait y avoir une sorte d'exemple sur la façon de transmettre les paramètres au travail cible. La page actuelle du plugin Parameterized Trigger Plugin ne donne pas de bonnes informations à ce sujet. Il peut y avoir par exemple le type de syntaxe à utiliser pour transmettre les paramètres.
skrii

2
Le plugin ne semble plus fonctionner. Consultez la longue liste des problèmes en suspens . Je ne peux plus transmettre de valeurs de paramètres avec ce plugin. Une autre solution?
Markus L

38

1.Actions post-build> Sélectionnez "Déclencher une build paramétrée sur d'autres projets"

2.Saisissez la variable d'environnement avec value.Value peut également être des paramètres de construction Jenkins.

Les étapes détaillées peuvent être vues ici: -

https://itisatechiesworld.wordpress.com/jenkins-related-articles/jenkins-configuration/jenkins-passing-a-parameter-from-one-job-to-another/

J'espère que c'est utile :)


Cette réponse répond à la question posée par OP sans nécessiter de plugin ni utiliser DSL.
BTC

8
Pour info, cette réponse a encore besoin du plugin.
Thomas Lee

Le plugin est génial quand mais il ne peut pas transmettre les valeurs de variable définies dans les sections de commande d'exécution du shell.
Tara Prasad Gurung

25

La réponse acceptée ici ne fonctionne pas pour mon cas d'utilisation. J'avais besoin de pouvoir créer dynamiquement des paramètres dans un travail et de les transmettre à un autre. Comme Mark McKenna le mentionne, il n'y a apparemment aucun moyen d'exporter une variable d'une étape de construction shell vers les actions post-build.

J'ai réalisé une solution de contournement en utilisant le plugin Parameterized Trigger en écrivant les valeurs dans un fichier et en utilisant ce fichier comme paramètres à importer via `` Ajouter une action post-construction '' -> `` Déclencher une construction paramétrée ... '' puis en sélectionnant `` Ajouter des paramètres '' - > 'Paramètres du fichier de propriétés'.


C'est ce dont j'avais besoin. Merci.
luckytaxi

Si vous souhaitez utiliser le pipeline jenkins 2.x, vous pouvez utiliser writeFile / stash-> unstash / readFile pour copier les données d'état entre les travaux. slideshare.net/ericlongtx/… Checkout slide 21 pour un exemple.
siesta

Ceci est nécessaire si vous voulez que les variables SHELL soient transmises. Très apprécié pour cette réponse.
Carl Wainwright

18

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, donc je voulais passer mon numéro de construction de travail en amont au travail en aval.J'ai essayé les étapes ci-dessus mais je n'ai pas pu le faire fonctionner. Voici comment cela a fonctionné:

  1. J'ai copié les artefacts de mon travail actuel en utilisant le plugin de copie d'artefacts.
  2. Dans l'action post build du travail en amont, j'ai ajouté la variable comme "SOURCE_BUILD_NUMBER = $ {BUILD_NUMBER}" et l'ai configuré pour déclencher le travail en aval.
  3. Tout a fonctionné sauf que mon travail en aval n'a pas pu obtenir $ SOURCE_BUILD_NUMBER pour créer le répertoire.
  4. 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 cette image ci-dessous:

entrez la description de l'image ici

En effet, la nouvelle version de jenkins vous oblige à définir également la variable dans le travail en aval. J'espère que c'est utile.


Entièrement d'accord. Il s'agit d'une mise à jour obligatoire qui complète à 100% la réponse initiale.
CodeSlave le

J'ai également essayé les deux options plus votées mais aucune de celles-ci n'a fonctionné jusqu'à l'ajout de la configuration supplémentaire décrite à l'étape 4 ci-dessus. Je n'avais pas besoin d'activer la copie d'artefacts pour que cela fonctionne.
Jeff Fol

10

(pour les collègues googleurs)

Si vous construisez un pipeline sérieux avec le plugin Build Flow , vous pouvez passer des paramètres entre les travaux avec le DSL comme ceci:

En supposant un paramètre de chaîne disponible "CVS_TAG", afin de le transmettre à d'autres jobs:

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 '------------------------------------'

Build Flow Plugin est obsolète, les utilisateurs doivent migrer vers wiki.jenkins-ci.org/display/JENKINS/Pipeline+Plugin
vhamon

7

Ajoutez simplement ma réponse en plus de celle de Nigel Kirby car je ne peux pas encore commenter:

Afin de passer un paramètre créé dynamiquement, vous pouvez également exporter la variable dans la vignette 'Execute Shell', puis la passer par 'Trigger parameterized build on other projects' => 'Paramètres prédéfinis "=> donnez' YOUR_VAR = $ YOUR_VAR '. Mon équipe utilise cette fonctionnalité pour passer la version du package npm de la tâche de construction aux tâches de déploiement

UPDATE: ci-dessus ne fonctionne que pour les paramètres injectés par Jenkins, les paramètres créés à partir du shell doivent toujours utiliser la même méthode. par exemple. echo YOUR_VAR = $ {YOUR_VAR}> variable.properties et passez ce fichier en aval


3

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'était d'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 le fichier de propriétés via le shell:

Construire des actions:

  • Exécuter un script shell
  • Injecter des variables d'environnement

Exemple: définition des propriétés

2) Passage des propriétés définies au travail en aval: Actions post-build:

  • Déclenchement paramétré sur un autre projet
  • Ajouter des paramètres: paramètres de construction actuels
  • Ajouter des paramètres: paramètres prédéfinis

Ex: envoi de propriétés

3) Il était alors possible d'utiliser $ POM_VERSION en tant que tel dans le travail Rundeck en aval.

/! \ Version Jenkins: 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 de construction actuels' pour transmettre les propriétés.


EDIT: J'ai trouvé un blooper dans ce que j'ai écrit. Dans la définition des propriétés, cela aurait dû être: echo POM_VERSION = $ POM_VERSION> play.properties et non: echo $ POM_VERSION >> play.properties Désolé pour cela.
Eli Mous

2

En lisant les réponses, je ne vois pas d'autre option qui me plait, je la proposerai également. J'adore le paramétrage des tâches, 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 transmettre les paramètres jusqu'au bout. Ou si vous avez un grand nombre de paramètres utilisés par une variété d'autres travaux (en particulier ceux qui ne sont pas nécessairement liés à un travail parent ou maître), encore une fois, le paramétrage ne fonctionne pas.

Dans ces cas, je préfère afficher les valeurs dans un fichier de propriétés, puis l'injecter dans le travail dont j'ai besoin en utilisant le plugin EnvInject . Cela peut être fait de manière dynamique, ce qui est une autre façon de résoudre le problème à partir d'une autre réponse ci-dessus où les travaux paramétrés étaient encore utilisés. Cette solution évolue très bien dans de nombreux scénarios.



0

Je l'ai compris!

Avec près de 2 heures d'essais et d'erreurs, j'ai compris.

Cela fonctionne et c'est ce que vous faites pour passer des variables à un travail distant:

    def handle = triggerRemoteJob(remoteJenkinsName: 'remoteJenkins', job: 'RemoteJob' paramters: "param1=${env.PARAM1}\nparam2=${env.param2}")

Utilisez \ n pour séparer deux paramètres, sans espaces.

Par opposition aux paramètres: '' 'someparams' ''

nous utilisons des paramètres: "someparams"

le "..." est ce qui nous donne les valeurs des variables souhaitées. (Ce sont des guillemets doubles, pas deux guillemets simples)

le '' '...' '' ou '...' ne nous donnera pas ces valeurs. (Trois guillemets simples ou juste des guillemets simples)

Tous les paramètres ici sont définis dans le bloc environnement {} au début du pipeline et sont modifiés par étapes> étapes> scripts si nécessaire.

J'ai également testé et constaté que lorsque vous utilisez "...", vous ne pouvez pas utiliser quelque chose comme "" ... "..." '' 'ou "...' ..'..." ou toute combinaison de il...

Le hic ici est que lorsque vous utilisez "..." dans la section des paramètres, vous ne pouvez pas passer un paramètre de chaîne; par exemple, cela ne fonctionnera pas:

    def handle = triggerRemoteJob(remoteJenkinsName: 'remoteJenkins', job: 'RemoteJob' paramters: "param1=${env.PARAM1}\nparam2='param2'")

si vous voulez passer quelque chose comme celui ci-dessus, vous devrez définir une variable d'environnement param2 = 'param2' puis utiliser $ {env.param2} dans la section des paramètres de l'étape du plugin de déclenchement à distance

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.