2015-11-07 9 views
11

Jenkins ha una variabile $ CAUSE disponibile per i lavori di creazione di stile libero.

Come posso accedere a questo o qualcosa di simile nel flusso di lavoro?

Il mio team lo utilizza nell'output di e-mail di build ad-hoc esistenti. Vorremmo continuare lo stesso con nuovi lavori basati sul flusso di lavoro.

risposta

17

Sembra che le build del flusso di lavoro non abbiano questa variabile iniettata. Tuttavia è possibile recuperare le informazioni richieste dall'oggetto currentBuild.rawBuild utilizzando il metodo hudson.model.Run.getCause() o hudson.model.Run.getCauses().

Esempio:

edizione Workflow:

println "CAUSE ${currentBuild.rawBuild.getCause(hudson.model.Cause$UserIdCause).properties}" 

risultati con questo output:

Running: Print Message 
CAUSE [userName:John Smith, userId:jsmith, class:class hudson.model.Cause$UserIdCause, shortDescription:Started by user John Smith] 

Altri sottotipi causa può essere trovata nel javadoc.

C'è anche un buon esempio get-build-cause che si basa su questa risposta nel repository jenkins Pipeline Examples.

+0

sembra che questo "lista nera", anche se, in base alla [codice sorgente] (https://github.com/jenkinsci/script- security-plugin/blob/master/src/main/resources/org/jenkinsci/plugins/scriptsecurity/sandbox/whitelists/blacklist # L45-L46), anche se non sono sicuro del perché. – mkobit

+0

Sì, è necessario approvare lo script o i metodi particolari o eseguire la sandbox esterna. – izzekil

+1

Questo non dovrebbe essere richiesto. Problema archiviato: https://issues.jenkins-ci.org/browse/JENKINS-41272 – BitwiseMan

1

Immagino si stia parlando di una macro definita nello Email Ext plugin. C'è ongoing work per far sì che il plugin supporti direttamente il flusso di lavoro. Non sono sicuro dello stato di questa macro specifica.

0

Nel caso in cui la build sia attivata da una build upstream, è necessario attraversare la gerarchia currentBuild.

Ad esempio:

println getCauser(currentBuild).userId 

@NonCPS 
def getCauser(def build) { 
    while(build.previousBuild) { 
     build = build.previousBuild 
    } 

    return build.rawBuild.getCause(hudson.model.Cause$UserIdCause) 
} 

Ciò restituirà l'ID utente della causa dell'utente originale.

4

Rispondo alla risposta di Jazzschmidt, dato che non ho abbastanza rep ... uno. Se quel lavoro è stato lanciato per la prima volta da qualcuno, è questo che otterrai. Altrimenti, la risposta sarà NULL, che causerà quindi un'eccezione nel tentativo di ottenere il suo ID utente.

Per ottenere la causa "originale", è necessario attraversare le cause utilizzando UpstreamCause. Questo è ciò che ho concluso sul fare, anche se ci possono essere altri modi:

@NonCPS 
def getCauser() { 
    def build = currentBuild.rawBuild 
    def upstreamCause 
    while(upstreamCause = build.getCause(hudson.model.Cause$UpstreamCause)) { 
    build = upstreamCause.upstreamRun 
    } 
    return build.getCause(hudson.model.Cause$UserIdCause).userId 
} 
+0

+1 per la correzione, ma sembra che si possa ottenere comunque un NPE se la causa principale non è un 'UserIdCause' (ad esempio' SCMTrigger.SCMTriggerCause', 'TimerTrigger.TimerTriggerCause') –

+0

Esatto. Non ho ampliato il codice per gestire altre cause, poiché questo era sufficiente per il mio caso d'uso. Per risolvere qualsiasi causa, l'ultima riga dovrebbe essere sostituita con qualcosa di simile al metodo formatCauses nel codice del plugin Email Ext, collegato a [risposta di Jesse Glick] (https://stackoverflow.com/a/34031927/ 8.020.250). – reist