Jak przekonać jenkins, aby udostępnił numer kompilacji dla kilku zadań?

Question

Mam wymaganie od zespołu programistycznego do skonfigurowania systemu kompilacji, aby każda kompilacja miała unikalny numer kompilacji dla wszystkich oddziałów.

Kompilacje są wykonywane przez jenkinsa przy użyciu zadań dla każdego oddziału.

Jest plugin Jenkins, który można ustawić następny buildNumber do pracy, ale jest to trochę bezużyteczne dla co najmniej dwóch powodów:

• będzie ustawić numer kompilacji dla pojedynczego zadania i nie można wiedzieć wszystko jak skonfigurować go do wszystkich oddziałów, ponieważ mogą one być usunięte lub dodane w dowolnym momencie
• nie ustawić go do obecnej wersji

Jak możemy uzyskać numery produkcji: robimy nawiązywać połączenia HTTP z nazwa oddziału i numer rewizji w git/mercurial. Na tej podstawie scentralizowany serwer podał nam numer kompilacji w odpowiedzi. Jeśli wywołasz go dwukrotnie z tymi samymi parametrami, otrzymasz taką samą odpowiedź (pożądane zachowanie).

Teraz, w jaki sposób możemy ulepszyć jenkins, aby używać tych samych numerów budowania co my? Oczywiście mogłem użyć numeru kompilacji zwrócony ze skryptu, ale numer zadania byłby inny i wątpię, aby jenkins wiedział, że dotknąłem zmiennej BUILD_NUMBER wewnątrz mojego skryptu.

Przede wszystkim potrzebuję jakiegoś skryptu przed uruchomieniem zadania, który można uruchomić, który będzie uruchamiany, zanim numer kompilacji zostanie przypisany do zadania.

Answer 1

Zapoznaj się z Build Name Setter Plugin i Description Setter Plugin. Używają funkcji RegEx i/lub zmiennych do ustawiania właściwości kompilacji po kompilacji, w oparciu o dane wyjściowe kompilacji.

Na przykład, można użyć tego wyrażenia regularnego:

At revision (\d)+ 

i ten ciąg zastępczy

Build number is ${BUILD_NUMBER}; Subversion revision \1 

można ustawić opis kompilacji za.

Jeśli zastępczy ciąg znaków nie zawiera czegoś unikatowego dla kompilacji (np. ${BUILD_NUMBER}), sugeruję, aby nie zmieniać nazwy kompilacji, ponieważ może istnieć kilka kompilacji dla tej samej wersji repozytorium.

---

Teraz, jak uzyskać kilka zadań zbudowanych na tej samej rewizji repozytorium to kolejna rzecz! Wygląda na to, że parameterized builds można uruchomić za pośrednictwem HTTP POST. Możesz więc mieć zadanie wyzwalane przez zmianę SCM i używać narzędzia HTTP (np. Wget) do planowania każdego sparametryzowanego zadania.

Answer 2

Można użyć Environment Injector Plugin do oceny skryptu Groovy przed uruchomieniem. Mam prawie taki sam wymóg, ale dla mnie tylko te same zadania o tej samej nazwie job_prefix_ mają tę samą unikatową nazwę: nextBuildNumber (innymi słowy, inne zadania o numerze job_prefix2_ w nazwie mają inną nazwę nextBuildNumber).

W sekcji Evaluated Groovy Script należy stosować:

import jenkins.model.* 

// Access to the Jenkins instance 
jenkins_instance = jenkins.model.Jenkins.instance 

// Select jobs that match. 
job_name = "^job_prefix_.*" 
allItems = jenkins_instance.items 
chosenJobs = allItems.findAll{ job -> job.name.matches(job_name) } 

// Get the max 
build_number = chosenJobs.collect{ it -> it.nextBuildNumber }.max() 

// Increase next build number 
currentJob.nextBuildNumber = build_number + 1 

// and use it. 
def map = [BUILD_NUMBER: build_number] 
return map 

Answer 3

Wziąłem dnozay's answer, ale przynajmniej dla Jenkins 1.586, to nie działa dobrze dla mnie. Oto problemy, które miałem:

1. Numer kompilacji w historii kompilacji Jenkinsa różni się od zmiennej BUILD_NUMBER używanej w pracy. Wygląda na to, że ustawienie BUILD_NUMBER w tym miejscu, nawet jeśli jest ustawione Override Build Parameters, jest za późno.
2. Następny numer kompilacji będzie obecny + 2, zamiast bieżącego +1. Myślę, że to dlatego, że nextBuildNumber jest zwiększany zarówno przez ten skrypt, jak i Jenkinsa.

Więc tutaj jest zaktualizowana wersja opiera się na jego odpowiedź:

import jenkins.model.* 

// Access to the Jenkins instance 
jenkinsInstance = jenkins.model.Jenkins.instance 

// Select jobs that match. 
jobName = "^job_prefix.*" 
allItems = jenkinsInstance.items 
chosenJobs = allItems.findAll{ job -> job.name.matches(jobName) } 

// Get the max 
buildNumber = chosenJobs.collect{ job -> job.nextBuildNumber }.max() 

// Increase next build number for all matching jobs 
chosenJobs.each{ job -> job.updateNextBuildNumber(buildNumber) } 

return [:] 

Znowu wszystko zasługa dnzay do oryginalnego scenariusza.

Edytuj: podczas tworzenia nowych zadań, stary musi być uruchomiony przed uruchomieniem nowych, w przeciwnym razie rozpocznie się od 1.