はすべての原因を取得するbuild.getCauses()
わけではなく、最初causeAction
のの原因のみを取得build.getActions(hudson.model.CauseAction.class)
するようです。build.getAction(hudson.model.CauseAction.class)
独自の原因を持つ追加のアクションは、次の方法で見つけることができます。
def actions = build.getActions(hudson.model.CauseAction.class)
そのため、これらの各アクションの原因を確認する必要があるため、代わりdef causes = build.causes()
に
def causes = build.getActions(hudson.model.CauseAction.class)
.collect{ it.getCauses() }.flatten()
私の場合、次のようなリストが返されます。
[ 05b8ef62-d071-11e8-b9db-9fd4e0aedf12/job/MyView/1238[11ef1ed2-d071-11e8-8c81-b71616102fe9/job/MyJob/4250[hudson.model.Cause$UserIdCause@2ddf7e3e]],
hudson.model.Cause$UserIdCause@3337c79c ]
最初のメンバーはビルド パイプライン プラグインupstreamCause
を表し、2 番目のメンバーはこのビルドを手動でトリガーしたユーザーを表します。
確かに、Build User Vars プラグインhudson.model.Cause$UserIdCause
が上流の原因ではなく、最も浅い を使用すること を望みます!
同様に、cause.upstreamCauses
各上流には複数の原因がある可能性があるため、チェーンを単純にたどっても意味がありません。
に沿って再帰する代わりに、次を使用して の原因アクションcause.upstreamCauses
にアクセスします。upstreamRun
cause.upstreamRun.getActions(hudson.model.CauseAction.class).collect{ it.getCauses() }.flatten()
ノート:
build.getCause(hudson.model.Cause$UserIdCause)
原因がであるアクションが存在する場合でも、NULL
どこで成功するかを返す可能性があるため、おそらくの代わりにも呼び出しますbuild.getCause(hudson.model.Cause$UpstreamCause)
getActions()
Cause$UserIdCause
getCause
getAction()
getActions()