2016-05-06 7 views
5

Stworzyłem nowy rurociąg Jenkinsa. Potok jest (obecnie) sparametryzowany za pomocą pojedynczej opcji boolowskiej o nazwie VAR_A. Rurociąg jest mój skrypt:Pass Jenkins buduje parametry dla węzłów potoku

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

Kiedy ręcznie zbudować projekt z VAR_A zaznaczone, „prawda” jest echem, jak oczekiwano. Lista zmiennych środowiskowych nie pokazuje jednak VAR_A=true.

jestem w stanie uzyskać env pokazać VAR_A jeśli mogę zawinąć wywołanie w withEnv bloku:

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

będę więcej parametrów niż to, więc wyszczególnieniem każdego parametru indywidualnie nie jest pożądane. Czy istnieje sposób przeniesienia wszystkich parametrów kompilacji do środowiska węzła?

Odpowiedz

8

Chodzi o to, że w skryptach potoku parametry zadania nie są automatycznie wprowadzane do środowiska, jak w przypadku zwykłych zadań. Każdy parametr staje się zmienną skryptu Pipeline binding. Dlatego możesz uzyskać do nich dostęp bezpośrednio po nazwie.

W twoim przykładzie podstawienie zmiennych odbywa się przez groovy w kontekście twojego skryptu (patrz Groovy doc on strings interpolation). Właśnie dlatego nie widzisz go na wyjściu bat.

Dla każdego parametru, który chcesz wstrzyknąć, należy dodać linię na poniższej ilustracji: env.VAR_A = VAR_A na początku skryptu. Może znajdować się poza blokiem node, ponieważ env jest globalny w całym skrypcie.

Alternatywnie istnieje sposób dodania wszystkich zmiennych skryptu, w tym parametrów, a nawet wbudowanych w ścianę potoków, tj. steps do środowiska. Niestety będzie to wymagało trochę whitelistingu uruchomić w piaskownicy:

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

Przykład: VAR_A jest parametrem. Script ciało:

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

W wyjściu bat znajdziesz VAR_A i BBBB.

IMO, chyba że Twoja praca ma dziesiątki zdefiniowanych parametrów. env.VAR_A = VAR_A Podejście jest preferowane, ponieważ jest prostsze, prostsze i nie wymaga zatwierdzeń.