Jak połączyć ręcznie uruchamiane zadanie końcowe, również przekazując parametry?

Używam Jenkinsa do tworzenia potoków budowania i trzeba wywołać etap wdrażania w potoku. Oznacza to proces ręczny (kompilacja odbywa się automatycznie, w określonym czasie, a następnie zatrzymuje się na etapie wdrażania, czekając na ręczną autoryzację).Jak połączyć ręcznie uruchamiane zadanie końcowe, również przekazując parametry?

Potrzebuję kroku wdrażania, aby być również wyzwalane za pomocą parametrów z poprzedniego kroku.

Używając "Sparametryzowanej wtyczki" mogę przekazywać parametry między zadaniami. Mogę wyzwolić zautomatyzowane LUB ręcznie uruchamiane zlecenia końcowe (nie jestem pewien, czy jest to standardowa funkcja, czy też niektóre wtyczki dodały ręczne kompilacje).

Jednak, Nie mogę znaleźć żadnego sposobu wyzwalania ręcznego sparametryzowanego zadania.

Czy ktoś wie, jak to zrobić? Czy mogę użyć innej wtyczki?

Powodem, dla którego potrzebuję parametrów jest to, że utworzyłem ogólne zadanie wdrażania i muszę podać nazwę modułu i wersję maven do wdrożenia. I could utworzyć konkretne zadania wdrażania dla każdego modułu, ale byłoby to bardzo bolesne.

Mam również pod uwagę następujące, ale wydaje się kludge:

Zautomatyzowana praca wykonuje budowy, wdrażania „spust” wyzwala budować, przekazywania parametrów.
„wyzwalania Deployment” pisze te parametry do pliku w systemie plików (build etap - wykonanie powłoki) i ręcznie wyzwala rzeczywiste pracy rozmieszczenie
pracy zdalnej instalacji (musi korzystać z przestrzeni roboczej z „Wdrażanie wyzwalania” pracy) odczytuje parametry z systemu plików (za pomocą wtyczki EnvInject).

Istnieją różne problemy z tym podejściem

po prostu nie podoba.

Ma pośrednie zlecenia tylko do przekazywania parametrów. To zaśmiecanie przestrzeni roboczej Jenkins

Jak buduje wykonywane są na tym samym obszarze roboczym wydaje mi się kruche (! Choć wykonalne)

Źródło

2012-08-16 GKelly

Czy kiedykolwiek wymyślić dopuszczalnego rozwiązanie tego? – Niklas

Nie. Na końcu automatycznie uruchomiłem zadanie pośrednie, przekazując parametry do tego. Spowoduje to ustawienie zmiennych środowiskowych w pliku w obszarze roboczym FS. Następnie uruchomiłem ręczny krok, aby uruchomić inne zadanie w środowisku _same_, które tworzy środowisko oparte na wcześniej ustawionym pliku środowiska. Hacky. – GKelly

Po prostu użyłem skryptu, aby wyświetlić echo myparameter = $ POM_VERSION >> version.properties na późniejszym etapie kompilacji. Następnie użył EnvInject do odczytu w wersji.properties w następnej kompilacji. –

Obecna wersja produkcyjna (1.4.2) wtyczki build-pipeline pozwala na określenie ręcznego zadania końcowego z parametrami, które są wyświetlane na potoku i można je uruchomić z tego miejsca. Stare wersje nie mogą tego zrobić.

Źródło

2014-03-28 07:36:05 Ivan

Jeszcze go nie wypróbowałem (i zrezygnowałem z projektu), ale zaufałbym temu pluginowi. – GKelly

Nadal nie mogę wykonać tej pracy. Podobnie jak OP, mogę zrobić to automatycznie i działa świetnie, ale ręczne nie. –

Miałem problem z automatycznymi uruchomieniami, które dominowały w biegach ręcznych. Okazuje się, że zadania zostały ustawione tak, aby były budowane, gdy uruchomiono inne zadanie zamiast polegać wyłącznie na wyzwalaczu ręcznym oferowanym przez wtyczkę build-pipeline. – J0hnG4lt

Spójrz u Zbuduj Pipeline Plugin: https://wiki.jenkins-ci.org/display/JENKINS/Build+Pipeline+Plugin.

Można określić zadania, które mają być wyzwalane automatycznie lub uruchamiane ręcznie.

Także jeśli trzeba parametru przepływających między pracy trzeba będzie pobrać Groovy Plugin: https://wiki.jenkins-ci.org/display/JENKINS/Groovy+plugin

Aby przekazać parametry powiedzmy rewizja SVN między pracy trzeba będzie Wykonanie systemu Groovy Script na początku twojej kompilacji. Jest to przykład, który doda parametr SVN_UPSTREAM, który może być używany przez dowolne kolejne zadania.UWAGA: Zauważyłem problem z tworzeniem zadania niższego rzędu, które również ma systemowy skrypt groovy. Wydaje się, że odrzuca wszelkie odniesienia do pierwotnie utworzonych parametrów.

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

Źródło

2012-09-20 20:51:02 user1687178

Problem polega na tym, że ustawienia, które należy ustawić dla kolejnych zadań, są oparte na materiałach generowanych podczas kompilacji (na przykład, przekazuję numer wersji wbudowanych artefaktów, który jest oparty na numerze kompilacji Jnkinsa i obliczonym value [wersja maven, minus '-SNAPSHOT]'). O ile mi wiadomo, skrypty systemowe mogą działać tylko na początku zadania. – GKelly

Próbowałem różnych wtyczek; build-pipeline-plugin, build-flow-plugin, sparametryzowane-wyzwalacz-plugin. Problem polega na tym, że żaden z nich nie oferuje tej funkcji. [Wtyczka build-flow wygląda obiecująco, ale nie nadążam za jej rozwojem. Może oferować tę funkcję teraz, nie wiem. Nie wspomina o niczym podobnym na stronie wiki]. – GKelly

Wygląda poprawnie w pracy nadrzędnej za pomocą groovy skrypt, ale nie przekazane dla mnie. – MikePatel

Plugin Build Pipeline może to zrobić, ale w chwili pisania tego tekstu, nie w żadnej opublikowanej wersji. Zbudowałem wtyczkę z głównego (rev 392 w tym czasie), która zawiera patch wspomnianą w this issue i działa dla mnie.
Po zainstalowaniu można w ramach pierwszego zadania użyć akcji "Buduj inne projekty (krok ręczny)", a następnie skonfigurować parametry, które mają zostać przekazane do drugiego (ręcznie uruchamianego) potoku praca.

Źródło

2013-01-14 13:18:48 Niklas

To jest obiecujące, ale wydaje się nie działać niestety.Mogę zlecić dalsze zadanie pracy z automatycznym zadaniem parametrów, ale nie ręczne. –

Jest to rodzaj obejścia:

ręcznej konfiguracji promocja (Promuj buduje kiedy ...> Tylko wtedy, gdy ręcznie zatwierdzony) w upstream pracy
w promocji określić dodać Działania> Wyzwalanie parametryzowane opierać się na inne projekty, określ zadanie i dodaj parametry

Po ręcznym promowaniu konkretnej kompilacji pracy upstream, zostanie uruchomiona kompilacja zlecenia downstream. Jednak dalsze zadanie nie pojawi się w potoku.

Źródło

2014-03-26 14:24:49 Ivan

Jest to akceptowalne obejście umożliwiające przekazywanie parametrów do ręcznego wyzwalacza. Niestety, w moim przypadku, moje ręczne uruchamianie wymaga również ręcznego wprowadzenia parametru, który nie zatrzymuje się i żąda w tym obejściu. –

Moim zdaniem nie ma możliwości, aby osiągnąć cel

Po uruchomieniu rurociągu kontrole zdawczo-rurociąg-plugin tylko parametry pierwszej pracy -> a następnie wyświetlacz (lub nie) na ekranie initParam

Ale kiedy następny krok (na przykład Deploy) jest instrukcja i to wymagane paramaters następnie ekran initParam jest ignorowany spojrzenie na kwestię https://issues.jenkins-ci.org/browse/JENKINS-32336

Źródło

2016-09-12 14:10:13

Jak połączyć ręcznie uruchamiane zadanie końcowe, również przekazując parametry?

Odpowiedz

Powiązane problemy