2012-08-16 9 views
11

Sto utilizzando Jenkins per creare una pipeline di build e devo attivare una fase di distribuzione nella pipeline. Ciò significa un processo manuale (la compilazione avviene automaticamente, cronometrata, quindi si ferma nella fase di implementazione, in attesa dell'autorizzazione manuale).Come concatenare un lavoro downstream attivato manualmente, passando anche i parametri?

Ho bisogno che la fase di distribuzione venga attivata anche con i parametri del passaggio precedente.

Quindi, utilizzando il 'Plugin parametrizzato' posso passare i parametri tra i lavori. Sono in grado di attivare i processi automatizzati o manualmente attivati ​​a valle (non sono sicuro che si tratti di una funzionalità standard o di aggiunte manuali da parte di alcuni plug-in).

Tuttavia, non riesco a trovare alcun modo per attivare un lavoro con parametri manuale.

Qualcuno sa di un modo per farlo? C'è un altro plugin che posso usare?

Il motivo per cui ho bisogno dei parametri è che ho creato un lavoro di distribuzione generico e devo passare il nome del modulo e la versione di Maven da distribuire. I potrebbe creare lavori di distribuzione specifici per ciascun modulo, ma ciò sarebbe molto doloroso.

Sono stato anche considerando i seguenti, ma sembra un ripiego:

  1. lavoro automatizzato esegue costruire, 'Trigger distribuzione' trigger costruire, i parametri di passaggio.
  2. 'innesco Deployment', scrive questi parametri in un file sul filesystem (build step - esecuzione della shell), e manualmente innesca l'attuale processo di distribuzione
  3. processo di distribuzione del (DEVE utilizzare l'area di lavoro dal 'grilletto distribuzione' di lavoro) legge i parametri dal filesystem (usando il plugin EnvInject).

Ci sono diversi problemi con questo approccio

  1. Io proprio non piace.
  2. Ha un lavoro intermedio solo per passare i parametri. Questo ingombra lo spazio di lavoro Jenkins
  3. Come generazioni sono effettuate sulla stessa area di lavoro, sembra fragile per me (! Se praticabile)
+0

hai mai arriva con una soluzione accettabile per questo? – Niklas

+0

No. Alla fine ho attivato automaticamente un lavoro intermedio, passando i parametri a questo. Ciò imposta le vars di ambiente in un file nell'area di lavoro FS. Quindi ho attivato un passaggio manuale per eseguire un altro lavoro nell'ambiente _same_, che imposta un ambiente basato sul file di ambiente impostato in precedenza. Hacky. – GKelly

+0

Ho appena usato uno script per echo myparameter = $ POM_VERSION >> version.properties in un secondo momento nella compilazione. Quindi ha utilizzato EnvInject per leggere in version.properties nella build successiva. –

risposta

6

La versione di produzione corrente (1.4.2) del plug-in build-pipeline consente di specificare il processo downstream manuale con i parametri, che viene visualizzato sulla pipeline e può essere avviato da lì. Le vecchie versioni non potevano farlo.

+0

Non ho ancora provato (e ho spostato il progetto), ma mi sarei fidato di questo plugin. – GKelly

+1

Ancora non riesco a farlo funzionare. Come l'OP, posso renderlo automatico e funziona benissimo, ma il manuale no. –

+0

Ho riscontrato un problema in cui le corse automatiche dominavano le esecuzioni manuali. Si scopre che i lavori sono stati impostati per essere costruiti quando è stato eseguito un altro lavoro anziché affidarsi esclusivamente al trigger manuale offerto dal plug-in build-pipeline. – J0hnG4lt

2

Date un'occhiata al Costruire Pipeline Plugin: https://wiki.jenkins-ci.org/display/JENKINS/Build+Pipeline+Plugin.

È possibile specificare i lavori da attivare automaticamente o manualmente.

Anche se avete bisogno di passaggio di parametri tra i lavori è necessario scaricare il Groovy Plugin: https://wiki.jenkins-ci.org/display/JENKINS/Groovy+plugin

Per passare parametri consente di dire una revisione SVN tra posti di lavoro è necessario Esegui sistema Groovy Script all'inizio della tua build. Questo è un esempio che aggiungerà un parametro SVN_UPSTREAM che può essere utilizzato da qualsiasi lavoro downstream.NOTA: Ho notato un problema con la creazione di un processo downstream che ha anche uno script groovy di sistema. Sembra spazzare via qualsiasi riferimento ai parametri originali creati.

import hudson.model.* 
def build = Thread.currentThread().executable; 
build.addAction(new ParametersAction(new StringParameterValue("SVN_UPSTREAM", build.getEnvVars()['SVN_REVISION']))); 
println "SVN_UPSTREAM:" + build.getEnvVars()['SVN_UPSTREAM']; 
+0

Il problema è che le impostazioni che devo impostare per i successivi lavori si basano su elementi generati durante la compilazione (ad esempio, passo il numero di versione delle risorse create, che è basato sul numero di build di jenkins e un calcolo value [versione di maven, meno '-SNAPSHOT]'). Per quanto ne so, gli script di sistema possono essere eseguiti solo all'inizio di un lavoro. – GKelly

+0

Ho provato vari plugin; build-pipeline-plug-in, build-flow-plugin, plug-in parametrico-trigger. Il problema è che nessuno di loro sembra offrire questa funzionalità. [Il plugin per il flusso di generazione sembra promettente, ma non ho tenuto il passo con il suo sviluppo. Potrebbe offrire questa funzionalità ora, non lo so. Tuttavia non menziona nulla di simile nella pagina wiki]. – GKelly

+0

Sembra corretto nel processo upstream utilizzando lo script groovy, ma non viene passato downstream per me. – MikePatel

1

Il plug-in Build Pipeline può fare questo, ma al momento della stesura di questo, non in qualsiasi versione rilasciata. Ho costruito il plugin da main (rev 392 alla volta), che include lo patch menzionato in this issue e funziona per me.
Quando è installato, è possibile utilizzare un'azione post-build chiamata "Genera altri progetti (passaggio manuale)" nel primo processo e lì è possibile configurare i parametri da passare alla seconda pipeline (ad attivazione manuale) lavoro.

+0

Questo è promettente, ma sembra che non funzioni purtroppo.Posso far sì che il lavoro downstream funzioni con il lavoro con parametri automatico, ma non con il manuale. –

2

C'è una sorta di soluzione alternativa:

  • configurazione promozione manuale (Promuovere costruisce quando ...> Solo quando approvato manualmente) in lavoro a monte
  • nella promozione specificare aggiungere azioni> trigger costruire parametrizzata su altri progetti, specificare lavoro e aggiungere parametri

Una volta che si promuove manualmente una generazione specifica di lavoro upstream, verrà generato un processo di produzione downstream. Ma il lavoro downstream non verrà visualizzato sulla pipeline.

+0

Questa è una soluzione accettabile per passare i parametri a un lavoro attivato manualmente. Sfortunatamente, nel mio caso, il mio lavoro con trigger manuale ha bisogno anche di un parametro inserito manualmente, che non si ferma e chiede in questa soluzione alternativa. –

0

A mio parere non c'è alcuna possibilità di raggiungere l'obiettivo

Quando si avvia i gasdotti controlli consegna-gasdotto-plug solo i parametri di primo impiego -> e poi display (o meno) lo schermo initParam

Ma quando passo successivo (ad esempio Deploy) è manuale ed è necessario paramaters allora lo schermo initParam viene ignorato sguardo al problema https://issues.jenkins-ci.org/browse/JENKINS-32336

Problemi correlati