2015-11-07 14 views
11

Jenkinsには、フリースタイルのビルドジョブで使用できる$ CAUSE変数があります。

ワークフローでこれにアクセスするにはどうすればよいですか?

私のチームは、既存のアドホックビルドのメール出力でこのチームを活用しています。新しいワークフローベースのジョブでも同じことを続けたいと思います。

答えて

17

ワークフロービルドにこの変数が注入されていないようです。 hudson.model.Run.getCause()またはhudson.model.Run.getCauses()メソッドを使用して、currentBuild.rawBuildオブジェクトから必要な情報を取得できます。

例:

ワークフロースクリプト:この出力で

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

結果:

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

他の原因のサブタイプがjavadocで見つけることができます。

また、この回答に基づくget-build-causeという良い例がjenkins Pipeline Examplesリポジトリにあります。

+0

それは、この「ブラックリストに載った」しかし、[ソースコード](に従ってhttps://github.com/jenkinsci/script-のようになります。これは私が他の方法があるかもしれませんが、やってしまったものですセキュリティプラグイン/ blob/master/src/main/resources/org/jenkinsci/plugins/scriptsecurity/sandbox/whitelists/blacklist#L45-L46) – mkobit

+0

はい、スクリプトや特定のメソッドを承認するか、サンドボックス外で実行する必要があります。 – izzekil

+1

これは本当に必要なものではありません。提出された問題:https://issues.jenkins-ci.org/browse/JENKINS-41272 – BitwiseMan

1

私はEmail Ext pluginで定義されたマクロについてお話していると思います。そのプラグインがワークフローを直接サポートするようにするには、ongoing workがあります。私はこの特定のマクロの状態についてはわかりません。

0

ビルドがアップストリームビルドによってトリガーされる場合は、currentBuildの階層をトラバースする必要があります。例えば

println getCauser(currentBuild).userId 

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

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

これは、元のユーザーの原因のユーザIDを返します。それは現在を立ち上げ、ない仕事と同じタイプの前に立ち上げた仕事を得るように私はちょうど十分な担当者を持っていないとして、私は、Jazzschmidtの答えに返信してい

4

は... previousBuildは、間違ったことをして1。その仕事が誰かによって最初に開始された場合、それはあなたが得るものです。それ以外の場合、レスポンスはNULLになり、userIdを取得しようとする例外が発生します。

「元の」原因を取得するには、UpstreamCauseを使用して原因をトラバースする必要があります。

@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を修正しましたが、根本的な原因が「UserIdCause」(つまり、「SCMTrigger.SCMTriggerCause」、「TimerTrigger.TimerTriggerCause」)でない場合は、とにかくNPEを取得する可能性が高いようです。 –

+0

そうです。私は他の原因を扱うコードを拡張しなかった。これは私の使用例では十分だったからだ。 原因を解析するには、最後の行を[Jesse Glickの答え](https://stackoverflow.com/a/34031927/)にリンクされているEmail ExtプラグインコードのformatCausesメソッドに似たものに置き換える必要があります。 8020250)。 – reist

関連する問題