Jenkins - passaggio di variabili tra i lavori?

Ho due lavori in jenkins, entrambi richiedono lo stesso parametro.

Come posso eseguire il primo lavoro con un parametro in modo che quando attiva il secondo lavoro, venga utilizzato lo stesso parametro?

Puoi utilizzare il plug-in trigger parametrizzato che ti consentirà di passare i parametri da un'attività all'altra.

Devi anche aggiungere questo parametro che hai passato da upstream a downstream.

1.Azioni post-compilazione> Seleziona "Attiva build parametrizzata su altri progetti"

2.Immettere la variabile d'ambiente con value.Value può anche essere Jenkins Build Parameters.

I passaggi dettagliati possono essere visualizzati qui: -

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

Spero sia utile :)

La risposta accettata qui non funziona per il mio caso d'uso. Dovevo essere in grado di creare dinamicamente parametri in un lavoro e passarli a un altro. Come afferma Mark McKenna, apparentemente non c'è modo di esportare una variabile da una fase di compilazione della shell alle azioni di post-compilazione.

Ho ottenuto una soluzione alternativa utilizzando il plug-in trigger parametrizzato scrivendo i valori in un file e utilizzando quel file come parametri da importare tramite "Aggiungi azione post-compilazione" -> "Attiva build parametrizzato ..." quindi selezionando "Aggiungi parametri" - > "Parametri dal file delle proprietà".

Penso che la risposta sopra abbia bisogno di qualche aggiornamento:

Stavo cercando di creare una directory dinamica per archiviare i miei artefatti di build upstream, quindi volevo passare il numero di build del mio lavoro upstream al lavoro downstream Ho provato i passaggi precedenti ma non sono riuscito a farlo funzionare. Ecco come ha funzionato:

1. Ho copiato gli artefatti dal mio lavoro corrente utilizzando il plug-in Copia artefatti.
2. Nell'azione di post build del lavoro upstream ho aggiunto la variabile come "SOURCE_BUILD_NUMBER = $ {BUILD_NUMBER}" e l'ho configurata per attivare il lavoro downstream.
3. Tutto ha funzionato tranne che il mio lavoro a valle non è stato in grado di ottenere $ SOURCE_BUILD_NUMBER per creare la directory.
4. Quindi ho scoperto che per usare questa variabile devo definire la stessa variabile nel lavoro a valle come una variabile parametro come in questa immagine qui sotto:

Questo perché la nuova versione di jenkins richiede che tu definisca la variabile anche nel lavoro a valle. Spero sia utile

(per colleghi googler)

Se stai costruendo una pipeline seria con Build Flow Plugin , puoi passare parametri tra i lavori con il DSL in questo modo:

Supponendo un parametro stringa disponibile "CVS_TAG", per passarlo ad altri lavori:

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

Suggerimento per la visualizzazione delle variabili / parametri disponibili:

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

Aggiungi la mia risposta oltre a quella di Nigel Kirby perché non posso ancora commentare:

Per passare un parametro creato dinamicamente, puoi anche esportare la variabile nel riquadro "Esegui shell" e quindi passarla attraverso "Trigger parametrizzato build su altri progetti" => "Parametri predefiniti" => dare "TUA_VAR = $ TUA_VAR". Il mio team utilizza questa funzionalità per passare la versione del pacchetto npm dal lavoro di compilazione ai lavori di distribuzione

AGGIORNAMENTO: sopra funziona solo per i parametri iniettati da Jenkins, il parametro creato dalla shell deve ancora utilizzare lo stesso metodo. per esempio. echo YOUR_VAR = $ {YOUR_VAR}> variable.properties e passa quel file a valle

Ho affrontato lo stesso problema quando ho dovuto passare una versione pom a un lavoro Rundeck a valle.

Quello che ho fatto è stato utilizzare l'iniezione di parametri tramite un file delle proprietà in quanto tale:

1) Creazione di proprietà nel file delle proprietà tramite shell:

Costruisci azioni:

• Esegui uno script di shell
• Iniettare variabili di ambiente

Ad esempio: definizione delle proprietà

2) Passaggio di proprietà definite al lavoro a valle: Azioni di post-compilazione:

• Attiva build parametrizzata su un altro progetto
• Aggiungi parametri: parametri di build correnti
• Aggiungi parametri: parametri predefiniti

Ad esempio: invio di proprietà

3) È stato quindi possibile utilizzare $ POM_VERSION come tale nel lavoro Rundeck a valle.

/! \ Versione Jenkins: 1.636.0

/! \ Per qualche motivo durante la creazione della build attivata, è stato necessario aggiungere l'opzione "Parametri build correnti" per passare le proprietà.

Leggendo le risposte, non vedo un'altra opzione che mi piace, quindi la offrirò anche. Amo la parametrizzazione dei lavori, ma non sempre scala bene. Se hai lavori che non sono direttamente a valle del primo lavoro ma più in basso nella pipeline, non vuoi veramente parametrizzare ogni lavoro nella pipeline in modo da poter passare i parametri fino in fondo. Oppure, se si dispone di un numero elevato di parametri utilizzati da una varietà di altri lavori (in particolare quelli non necessariamente legati a un lavoro principale o principale), ancora una volta la parametrizzazione non funziona.

In questi casi, preferisco l'output dei valori in un file delle proprietà e quindi l'iniezione in qualsiasi lavoro di cui ho bisogno utilizzando il plug-in EnvInject . Questo può essere fatto dinamicamente, che è un altro modo per risolvere il problema da un'altra risposta precedente in cui erano ancora utilizzati lavori parametrizzati. Questa soluzione scala molto bene in molti scenari.

Puoi usare Hudson Groovy Builder per farlo.

Primo lavoro in cantiere

Secondo lavoro in cantiere

L'avevo capito!

Con quasi 2 ore di tentativi ed errori, l'ho capito.

Questo FUNZIONA ed è ciò che fai per passare le variabili al lavoro remoto:

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

Usa \ n per separare due parametri, senza spazi ..

Al contrario dei parametri: '' 'someparams' ''

usiamo i parametri: "someparams"

il "..." è ciò che ci fornisce i valori delle variabili desiderate. (Queste sono virgolette doppie, non due virgolette singole)

'' '...' '' o '...' non ci forniranno questi valori. (Tre virgolette singole o solo virgolette singole)

Tutti i parametri qui sono definiti nel blocco di ambiente {} all'inizio della pipeline e vengono modificati in fasi> passaggi> script ove necessario.

Ho anche testato e scoperto che quando usi "..." non puoi usare qualcosa come '' '... "..."' '' o "... '..'..." o qualsiasi combinazione di esso ...

Il problema qui è che quando si utilizza "..." nella sezione dei parametri, non è possibile passare un parametro stringa; per esempio questo NON FUNZIONA:

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

se vuoi passare qualcosa di simile a quello sopra, dovrai impostare una variabile d'ambiente param2 = 'param2' e quindi utilizzare $ {env.param2} nella sezione parametri del passaggio del plug-in del trigger remoto