Jenkins - przekazywanie zmiennych między zadaniami?

Mam dwie prace w Jenkins, z których obie wymagają tego samego parametru.

Jak mogę uruchomić pierwsze zadanie z parametrem, aby po wyzwoleniu drugiego zadania używany był ten sam parametr?

Możesz użyć sparametryzowanej wtyczki wyzwalacza, która pozwoli ci przekazywać parametry z jednego zadania do drugiego.

Musisz również dodać ten parametr, który przekazałeś z góry w dół.

1. Działania po kompilacji> Wybierz „Wyzwalanie sparametryzowanej kompilacji na podstawie innych projektów”

2.Wprowadź zmienną środowiskową z wartością. Wartość może być również parametrami kompilacji Jenkinsa.

Szczegółowe kroki można zobaczyć tutaj: -

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

Mam nadzieję, że to pomocne :)

Odpowiedź Akceptowane tutaj nie działa dla mojego przypadku użycia. Musiałem mieć możliwość dynamicznego tworzenia parametrów w jednym zadaniu i przekazywania ich do innego. Jak wspomina Mark McKenna, pozornie nie ma możliwości wyeksportowania zmiennej z etapu budowania powłoki do działań po kompilacji.

Osiągnąłem obejście problemu za pomocą sparametryzowanej wtyczki wyzwalacza , zapisując wartości do pliku i używając tego pliku jako parametrów do zaimportowania za pomocą opcji „Dodaj akcję po kompilacji” -> „Wyzwalanie sparametryzowanej kompilacji ...”, a następnie wybierając opcję „Dodaj parametry” - > „Parametry z pliku właściwości”.

Myślę, że powyższa odpowiedź wymaga aktualizacji:

Próbowałem utworzyć katalog dynamiczny do przechowywania moich artefaktów kompilacji nadrzędnej, więc chciałem przekazać numer kompilacji zadania nadrzędnego do zadania podrzędnego. Wykonałem powyższe kroki, ale nie mogłem sprawić, by działało. Oto jak to działało:

1. Skopiowałem artefakty z mojej obecnej pracy za pomocą wtyczki kopiowania artefaktów.
2. W akcji po kompilacji zadania nadrzędnego dodałem zmienną taką jak „SOURCE_BUILD_NUMBER = $ {BUILD_NUMBER}” i skonfigurowałem ją tak, aby wyzwalała zadanie podrzędne.
3. Wszystko działało z wyjątkiem tego, że moje dalsze zadanie nie było w stanie uzyskać $ SOURCE_BUILD_NUMBER, aby utworzyć katalog.
4. Więc dowiedziałem się, że aby użyć tej zmiennej, muszę zdefiniować tę samą zmienną w zadaniu downstream jako zmienną parametru, jak na poniższym obrazku:

Dzieje się tak, ponieważ nowa wersja jenkins wymaga zdefiniowania zmiennej również w kolejnym zadaniu. Mam nadzieję, że to pomocne.

(dla innych pracowników Google)

Jeśli tworzysz poważny potok za pomocą wtyczki Build Flow , możesz przekazywać parametry między zadaniami za pomocą DSL w następujący sposób:

Przypuśćmy, że dostępny parametr ciągu „CVS_TAG”, aby przekazać go do innych zadań:

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

Wskazówka dotycząca wyświetlania dostępnych zmiennych / parametrów:

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

Po prostu dodaj moją odpowiedź oprócz odpowiedzi Nigela Kirby'ego, ponieważ nie mogę jeszcze komentować:

Aby przekazać dynamicznie utworzony parametr, możesz również wyeksportować zmienną w kafelku „Execute Shell”, a następnie przekazać ją przez „Trigger parametryzowana kompilacja w innych projektach” => „Predefiniowane parametry” => podaj „YOUR_VAR = $ YOUR_VAR”. Mój zespół używa tej funkcji do przekazywania wersji pakietu npm z zadania kompilacji do zadań wdrożeniowych

UPDATE: powyższe działa tylko dla parametrów wstrzykniętych przez Jenkinsa, parametr utworzony z powłoki nadal musi używać tej samej metody. na przykład. echo YOUR_VAR = $ {YOUR_VAR}> variable.properties i przekaż ten plik w dół

Napotkałem ten sam problem, gdy musiałem przekazać wersję pom do pracy w Rundeck niższego szczebla.

To, co zrobiłem, polegało na użyciu wstrzyknięcia parametrów za pośrednictwem pliku właściwości jako takiego:

1) Tworzenie właściwości w pliku properties za pomocą powłoki:

Tworzenie działań:

• Wykonaj skrypt powłoki
• Wstaw zmienne środowiskowe

Np .: definicja właściwości

2) Przekazywanie zdefiniowanych właściwości do następnego zadania: Działania po kompilacji:

• Wyzwalanie sparametryzowanej kompilacji w innym projekcie
• Dodaj parametry: aktualne parametry kompilacji
• Dodaj parametry: wstępnie zdefiniowane parametry

Np .: wysyłanie właściwości

3) Wtedy było możliwe użycie $ POM_VERSION jako takiej w zadaniu Rundeck.

/! \ Jenkins Wersja: 1.636.0

/! \ Z jakiegoś powodu podczas tworzenia wyzwalanej kompilacji konieczne było dodanie opcji „Bieżące parametry kompilacji”, aby przekazać właściwości.

Czytając odpowiedzi, nie widzę innej opcji, która mi się podoba, więc również ją zaoferuję. Uwielbiam parametryzację zadań, ale nie zawsze dobrze się ona skaluje. Jeśli masz zadania, które nie znajdują się bezpośrednio poniżej pierwszego zadania, ale dalej w dół potoku, tak naprawdę nie chcesz parametryzować każdego zadania w potoku, aby móc przekazać parametry przez całą drogę. Lub jeśli masz dużą liczbę parametrów używanych przez różne inne zadania (zwłaszcza te niekoniecznie powiązane z jednym zadaniem nadrzędnym lub głównym), ponownie parametryzacja nie działa.

W takich przypadkach wolę wyprowadzać wartości do pliku właściwości, a następnie wstrzykiwać je w dowolnym zadaniu za pomocą wtyczki EnvInject . Można to zrobić dynamicznie, co jest kolejnym sposobem rozwiązania problemu z innej odpowiedzi powyżej, w której nadal były używane sparametryzowane zadania. To rozwiązanie bardzo dobrze skaluje się w wielu scenariuszach.

Możesz do tego użyć kreatora Hudson Groovy .

Pierwsza praca w przygotowaniu

Druga praca w przygotowaniu

Rozgryzłem to!

Z prawie 2-godzinną próbą i błędem zrozumiałem to.

To DZIAŁA i co robisz, aby przekazać zmienne do zadania zdalnego:

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

Użyj \ n, aby oddzielić dwa parametry, bez spacji.

W przeciwieństwie do parametrów: '' 'someparamy' ''

używamy parametrów: „someparams”

„…” jest tym, co daje nam wartości pożądanych zmiennych. (Są to podwójne cudzysłowy, a nie dwa pojedyncze cudzysłowy)

'' '...' '' lub '...' nie dostarczy nam tych wartości. (Trzy pojedyncze cudzysłowy lub tylko pojedyncze cudzysłowy)

Wszystkie parametry są tutaj zdefiniowane w bloku środowiska {} na początku potoku i są modyfikowane etapami> kroki> skrypty, gdy jest to konieczne.

Przetestowałem również i stwierdziłem, że kiedy używasz „...”, nie możesz użyć czegoś takiego jak „'' '...” ... ”' '' lub„ ... '..'... ”ani dowolnej kombinacji to...

Haczyk polega na tym, że kiedy używasz "..." w sekcji parametrów, nie możesz przekazać parametru typu string; na przykład to NIE DZIAŁA:

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

jeśli chcesz przekazać coś podobnego do powyższego, musisz ustawić zmienną środowiskową param2 = 'param2', a następnie użyć $ {env.param2} w sekcji parametrów kroku wtyczki zdalnego wyzwalacza