Come faccio a generare dinamicamente build downstream in jenkins?

Question

Vogliamo attivare dinamicamente i test di integrazione in diversi build downstream in jenkins. Abbiamo un progetto di test di integrazione parametrizzato che prende come nome un nome di prova. Determiniamo dinamicamente i nostri nomi di test dal repository git.

Abbiamo un progetto padre che utilizza jenkins-cli per avviare una build del progetto di integrazione per ogni test trovato nel codice sorgente. Il progetto principale e il progetto di integrazione sono correlati tramite fingerprint corrispondenti.

Il problema con questo approccio è che i risultati dei test aggregati non funzionano. Penso che il problema è che i test di integrazione "downstream" sono avviati tramite jenkins-cli, quindi jenkins non si rende conto che sono a valle.

Ho esaminato molti plugin jenkins per provare a farlo funzionare. I plug-in Join e Parameterized Trigger non aiutano perché si aspettano una lista statica di progetti da costruire. Le factory dei parametri disponibili per Parameterized Trigger non funzioneranno perché non esiste una factory per creare un elenco arbitrario di parametri. Il plug-in Log Trigger non funzionerà.

Il plugin Groovy Postbuild sembra funzionare correttamente, ma non sono riuscito a capire come attivare una build da esso.

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) 

Questo è ciò che alla fine ha funzionato per me.

Answer 2

Dato che si stanno già iniziando i processi downstream in modo dinamico, che ne dici di aspettare fino a quando non hanno finito e copiare i file dei risultati del test (li archiverei nei processi downstream e quindi scarichi le risorse "build") nell'area di lavoro padre . Potrebbe essere necessario aggregare manualmente i file, a seconda che il plug-in Test possa funzionare con diverse pagine dei risultati dei test. Nel passaggio di post produzione dei processi padre, configurare il plug-in di test appropriato.

Answer 3

Utilizzando la Postbuild plugin Groovy, forse qualcosa di simile a questo lavoro (non ho provato)

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

Sono davvero sorpreso che se entrambi i lavori di impronte digitali (ad esempio con la variabile BUILD_TAG del processo padre) i risultati aggregati non vengono raccolti. Nella mia comprensione Jenkins guarda semplicemente md5sum per mettere in relazione i lavori (Aggregate downstream test results e l'attivazione tramite il cli non dovrebbe influenzare i risultati di aggregazione.In qualche modo, c'è qualcosa di aggiuntivo in corso per mantenere la relazione upstream/downstream di cui non sono a conoscenza ...

Answer 4

NOTA: Il Pipeline Plugin dovrebbe rendere questa questione controversa, ma non ho avuto la possibilità di aggiornare la nostra infrastruttura

per avviare un lavoro a valle senza parametri:.

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) 

Per avviare un processo downstream con i parametri, è necessario aggiungere un ParametersAction. Supponiamo che Job1 contenga i parametri A e C che predefiniscono rispettivamente su "B" e "D". Cioè .:

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

supponga Job2 ha gli stessi parametri A e B, ma richiede anche parametro E cui valore predefinito "F".Il seguente post script di generazione in Job1 copierà i suoi A e C parametri e impostare il parametro E alla concatenazione di A 's e C' valori 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 
) 

È necessario aggiungere $JENKINS_HOME/plugins/parameterized-trigger/WEB-INF/classes a quello del Additional groovy classpath plug Groovy Postbuild.

Answer 5

questo ha lavorato per me usando "Esegui sistema Groovy script"

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

eseguire questo script Groovy

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")])) 
} 

Se non si ha bisogno di passare nelle proprietà da una costruzione all'altra basta prendere i ParametersAction.

La build pianificata avrà la stessa "causa" della build iniziale. È un bel modo per passare le "Modifiche". Se non ne hai bisogno, non utilizzare la nuova causa.UpstreamCause (build) nella chiamata di funzione