2015-11-07 10 views
11

Jenkins ma zmienną $ CAUSE dostępną dla zadań tworzenia freestyle.

Jak uzyskać dostęp do tego lub coś podobnego w obiegu pracy?

Mój zespół korzysta z niego w wynikach e-mail istniejących kompilacji ad-hoc. Chcemy kontynuować to samo w nowych zadaniach opartych na przepływie pracy.

Odpowiedz

17

Wygląda na to, że kompilacje Workflow nie mają wprowadzonej tej zmiennej. Można jednak pobrać wymagane informacje z obiektu currentBuild.rawBuild przy użyciu metody hudson.model.Run.getCause() lub hudson.model.Run.getCauses().

przykład:

skrypt Workflow:

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

wyniki z tego wyjścia:

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

innej przyczyny podtypy można znaleźć w javadoc.

Istnieje również dobry przykład get-build-cause, który jest oparty na tej odpowiedzi w repozytorium jenkins Pipeline Examples.

+0

wygląda to tak „czarnej liście”, choć, zgodnie z [kod źródłowy] (https://github.com/jenkinsci/script- security-plugin/blob/master/src/main/resources/org/jenkinsci/plugins/scriptsecurity/sandbox/whitelists/blacklist # L45-L46), chociaż nie jestem pewien dlaczego. – mkobit

+0

Tak, musisz zatwierdzić skrypt lub określone metody lub uruchomić na zewnątrz obszaru izolowanego. – izzekil

+1

To naprawdę nie powinno być wymagane. Zapisano problem: https://issues.jenkins-ci.org/browse/JENKINS-41272 – BitwiseMan

1

Chyba mówisz o makro zdefiniowanym w Email Ext plugin. Jest ongoing work, aby ta wtyczka bezpośrednio obsługiwała Workflow. Nie jestem pewien co do statusu tego konkretnego makra.

0

Jeśli kompilacja jest uruchamiana przez kompilację upstream, musisz przejść przez hierarchię currentBuild.

Na przykład

println getCauser(currentBuild).userId 

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

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

powoduje przywrócenie identyfikator użytkownika pierwotnej przyczyny użytkownika.

4

Odpowiadam na odpowiedź Jazzschmidta, ponieważ nie mam wystarczającej liczby rep ... previousBuild robi źle, ponieważ dostaje poprzednio uruchomioną pracę tego samego typu, a nie pracę, która uruchomiła bieżący jeden. Jeśli ta praca została po raz pierwszy uruchomiona przez kogoś, dostaniesz to. W przeciwnym razie odpowiedź będzie miała wartość NULL, co spowoduje wyjątek próbujący uzyskać jego identyfikator użytkownika.

Aby uzyskać przyczynę "oryginalną", musisz przejść przez przyczyny używając UpstreamCause. To, co skończyło się robi, chociaż mogą istnieć inne sposoby:

@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 za korektę, ale wygląda na to, że prawdopodobnie uzyskasz NPE, jeśli główną przyczyną nie jest "UserIdCause" (tj. "SCMTrigger.SCMTriggerCause", "TimerTrigger.TimerTriggerCause") –

+0

Zgadza się. Nie rozszerzyłem kodu, aby poradzić sobie z innymi przyczynami, ponieważ było to wystarczające dla mojego przypadku użycia. Aby przeanalizować dowolną przyczynę, ostatnia linia musiałaby zostać zastąpiona przez coś podobnego do metody formatCauses w kodzie wtyczki Email Ext, połączonej z [odpowiedź Jesse Glicka] (https://stackoverflow.com/a/34031927/ 8020250). – reist