2016-05-06 12 views
5

Ich habe eine neue Jenkins-Pipeline erstellt. Die Pipeline wird (derzeit) mit einer einzigen booleschen Option namens VAR_A parametrisiert. Meine Pipeline-Skript ist:Pass Jenkins Build-Parameter zu Pipeline-Knoten

node ('windows') { 
    echo "$VAR_A" 
    bat 'env' 
} 

Wenn ich das Projekt manuell erstellen mit VAR_A geprüft, „true“ Echo wird, wie erwartet. Die Liste der Umgebungsvariablen zeigt jedoch VAR_A=true nicht.

Ich bin in der Lage env zu bekommen VAR_A zu zeigen, wenn ich den Anruf in einem withEnv Block wickeln:

node ('windows') { 
    echo "$VAR_A" 
    withEnv(["VAR_A=$VAR_A"]) { 
     bat 'env' 
    } 
} 

Ich werde mehr Parameter als diese, so jeden Parameter einzeln Angabe nicht erwünscht ist. Gibt es eine Möglichkeit, alle Build-Parameter in die Umgebung eines Knotens zu übertragen?

Antwort

8

Der Punkt ist, dass in Pipeline-Skripten die Job-Parameter nicht automatisch in die Umgebung wie für reguläre Jobs injiziert werden. Jeder Parameter wird zu einer Variablen des Pipeline-Skripts binding. Daher können Sie direkt auf den Namen zugreifen.

In Ihrem Beispiel echo "$VAR_A" Variablensubstitution wird von groovy im Zusammenhang mit Ihrem Skript durchgeführt (siehe Groovy doc on strings interpolation). Deshalb sehen Sie es nicht im bat Ausgang.

Für jeden Parameter, den Sie injizieren möchten, müssen Sie eine Zeile wie folgt hinzufügen: env.VAR_A = VAR_A am Anfang Ihres Skripts. Es kann außerhalb von node Block sein, da env innerhalb des gesamten Skripts global ist.

Alternativ gibt es eine Möglichkeit, alle Skript-Vars, einschließlich Parameter und sogar Pipeline integrierte Vars, d. H. steps in die Umgebung hinzuzufügen. Leider wird es einige weißen Listen erfordern in einer Sandbox auszuführen:

@NonCPS 
def populateEnv(){ binding.variables.each{k,v -> env."$k" = "$v"} } 
populateEnv() 

Beispiel: Var_a ist ein Parameter. Script Körper:

def AAAA = 1 // such a definition doesn't put variable in the binding 
BBBB = 2  // creates a binding variable. Absolutely the same behavior as for a job parameter. 

@NonCPS 
def populateEnv(){ binding.variables.each{k,v -> env."$k" = "$v"} } 
populateEnv() // at this point injection happens 

CCCC = 3  // created after the injection hence it won't appear in env. 
node ('windows') { 
    bat 'env' 
} 

Im bat Ausgang Sie VAR_A und BBBB finden.

IMO, es sei denn, Ihr Job hat Dutzende von Parametern definiert env.VAR_A = VAR_A Ansatz wird als einfacher, unkompliziert und erfordert keine Genehmigungen.