Jak dynamicznie uruchamiać kompilacje downstream w jenkins?

Question

Chcemy dynamicznie uruchamiać testy integracji w różnych niższych wersjach w jenkins. Mamy sparametryzowany projekt testu integracji, który przyjmuje nazwę testu jako parametr. Dynamicznie ustalamy nasze nazwy testowe z repozytorium git.

Mamy projekt nadrzędny, który wykorzystuje jenkins-cli do rozpoczęcia kompilacji projektu integracji dla każdego testu znalezionego w kodzie źródłowym. Projekt nadrzędny i projekt integracji są powiązane za pomocą pasujących odcisków palców.

Problem z tym podejściem polega na tym, że zbiorcze wyniki testu nie działają. Myślę, że problem polega na tym, że testy integracyjne "w dół" są uruchamiane za pośrednictwem Jenkins-cli, więc Jenkins nie zdaje sobie sprawy z tego, że są w dalszej części.

Sprawdziłem wiele wtyczek Jennkins, aby spróbować działać. Wtyczki Join i Parameterized Trigger nie pomagają, ponieważ oczekują statycznej listy projektów do zbudowania. Fabryki parametrów dostępne dla Sparametryzowanego Triggera również nie będą działały, ponieważ nie ma fabryki, która utworzyłaby dowolną listę parametrów. Wtyczka Log Trigger nie będzie działać.

Plugin Groovy Postbuild wygląda na to, że powinien działać, ale nie mogłem wymyślić, jak wyzwolić z niego kompilację.

Answer 1

def job = hudson.model.Hudson.instance.getJob("job") 
def params = new StringParameterValue('PARAMTEST', "somestring") 
def paramsAction = new ParametersAction(params) 
def cause = new hudson.model.Cause.UpstreamCause(currentBuild) 
def causeAction = new hudson.model.CauseAction(cause) 
hudson.model.Hudson.instance.queue.schedule(job, 0, causeAction, paramsAction) 

Właśnie to dla mnie zadziałało.

Answer 2

Ponieważ zadania dynamiczne są już uruchamiane dynamicznie, można je poczekać do momentu skopiowania plików wyników testu (zarchiwizować je w dalszych zleceniach, a następnie pobrać artefakty "kompilacji") do nadrzędnego obszaru roboczego . Konieczne może być ręczne agregowanie plików, w zależności od tego, czy wtyczka testowa może działać z kilkoma stronami wyników testu. W kroku tworzenia postu zadań nadrzędnych skonfiguruj odpowiednią wtyczkę testową.

Answer 3

Korzystanie z Groovy Postbuild wtyczki, może coś jak to będzie działać (nie próbowałem)

def job = hudson.getItem(jobname) 
hudson.queue.schedule(job) 

Jestem naprawdę zaskoczony, że jeśli odciski palców obu miejsc pracy (np ze zmienną BUILD_TAG zadania nadrzędnego) zagregowane wyniki nie zostały zebrane. W moim rozumieniu Jenkins po prostu patrzy na md5sums w celu powiązania zadań (Aggregate downstream test results, a wyzwalanie przez cli nie powinno wpływać na wyniki agregacji.) W jakiś sposób dzieje się coś dodatkowego, aby utrzymać relację w górę/w dół, o której nie wiem ...

Answer 4

UWAGA: Pipeline Plugin powinien uczynić to pytanie dyskusyjna, ale nie miałem szansy, aby zaktualizować naszą infrastrukturę

aby rozpocząć pracę bez dalszego parametrów.

job = manager.hudson.getItem(name) 
cause = new hudson.model.Cause.UpstreamCause(manager.build) 
causeAction = new hudson.model.CauseAction(cause) 
manager.hudson.queue.schedule(job, 0, causeAction) 

Aby rozpocząć zadanie niższego rzędu z parametrami, musisz dodać ParametersAction. Załóżmy, że Job1 ma parametry A i C, które domyślnie mają wartości "B" i "D". Tj .:

A == "B" 
C == "D" 

Załóżmy Job2 ma takie same parametry a i b, lecz również wykonuje parametr E które domyślnie „F”.Następujący po kompilacji skryptu w Job1 skopiuje jego A i C parametrów i zestaw parametrów E do konkatenacji A „s i C” wartości s:

params = [] 
val = '' 
manager.build.properties.actions.each { 
    if (it instanceof hudson.model.ParametersAction) { 
     it.parameters.each { 
      value = it.createVariableResolver(manager.build).resolve(it.name) 
      params += it 
      val += value 
     } 
    } 
} 

params += new hudson.model.StringParameterValue('E', val) 
paramsAction = new hudson.model.ParametersAction(params) 

jobName = 'Job2' 
job = manager.hudson.getItem(jobName) 
cause = new hudson.model.Cause.UpstreamCause(manager.build) 
causeAction = new hudson.model.CauseAction(cause) 
def waitingItem = manager.hudson.queue.schedule(job, 0, causeAction, paramsAction) 
def childFuture = waitingItem.getFuture() 
def childBuild = childFuture.get() 

hudson.plugins.parameterizedtrigger.BuildInfoExporterAction.addBuildInfoExporterAction(
    manager.build, childProjectName, childBuild.number, childBuild.result 
) 

Trzeba dodać $JENKINS_HOME/plugins/parameterized-trigger/WEB-INF/classes do Groovy Postbuild pluginu Additional groovy classpath.

Answer 5

ten pracował dla mnie za pomocą „Wykonanie systemu groovy skrypt”

import hudson.model.* 

def currentBuild = Thread.currentThread().executable 

def job = hudson.model.Hudson.instance.getJob("jobname") 
def params = new StringParameterValue('paramname', "somestring") 
def paramsAction = new ParametersAction(params) 
def cause = new hudson.model.Cause.UpstreamCause(currentBuild) 
def causeAction = new hudson.model.CauseAction(cause) 
hudson.model.Hudson.instance.queue.schedule(job, 0, causeAction, paramsAction) 

Answer 6

Wykonaj ten Groovy skrypt

import hudson.model.* 
import jenkins.model.* 

def build = Thread.currentThread().executable 

def jobPattern = "PUTHEREYOURJOBNAME"  
def matchedJobs = Jenkins.instance.items.findAll { job -> 
    job.name =~ /$jobPattern/ 
} 
matchedJobs.each { job -> 
    println "Scheduling job name is: ${job.name}" 
    job.scheduleBuild(1, new Cause.UpstreamCause(build), new ParametersAction([ new StringParameterValue("PROPERTY1", "PROPERTY1VALUE"),new StringParameterValue("PROPERTY2", "PROPERTY2VALUE")])) 
} 

Jeśli nie trzeba przekazać właściwości z jednej budowy na drugą po prostu wyłącz funkcję ParametersAction.

Planowana kompilacja będzie miała tę samą "przyczynę" co początkowa kompilacja. To dobry sposób na przekazanie "zmian". Jeśli nie potrzebujesz tego, po prostu nie używaj nowej funkcji Cause.UpstreamCause (kompilacja) w wywołaniu funkcji