Jenkins - passer des variables entre les travaux?

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é?

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.

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 :)

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

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:

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.

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

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

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.

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.

Vous pouvez utiliser le générateur Hudson Groovy pour ce faire.

Premier emploi en cours

Deuxième emploi en pipeline

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