有没有一种方法可以在执行过程中识别当前构建的触发器。我想要的是确定触发器是SCM更改、cron触发器还是用户触发器。我为一个作业定义了多个触发器，并希望在shell执行脚本中使用触发器类型作为参数。
vshtjzan1#
您可以使用Rest API获取此信息;下面是一个示例：http://jenkins.yourdomain.com/job/job_name/build_number/api/json?tree=actions[causes[shortDescription]]&pretty=true返回
{ "actions" : [ { "causes" : [ { "shortDescription" : "Started by an SCM change" } ] }, { }, { }, { }, { }, { }, { } ] }
de90aj5v2#
一种解决方案是使用Run Condition Plugin，它可以根据触发器类型运行不同的shell脚本。这不是一个完美的解决方案，但它会做你想要的。
5us2dqdw3#
你也可以使用groovy script。看看我对Jenkins Groovy的回答：什么触发了构建，您可以获取Cause对象，然后检查它是http://javadoc.jenkins-ci.org/hudson/model/Cause.html的哪个子类型
yqhsw0fo4#
在http（s）：//（your-jenkins-server）/jenkins/job/（job-name）/（job-number）的“Build Artifacts”和“Changes”部分（如果有的话）下，您应该会看到这个图标：x1c 0d1x。它旁边的文本应该说明导致构建的原因。
rta7y2nd5#
您可以从任何地方访问所谓的构建原因（即，也在沙盒中）到达currentBuild.getBuildCauses，这会为您提供当前原因及其一些属性的JSON（类型化，但通常仍然可迭代）列表，例如：
currentBuild.getBuildCauses
[ [ _class: 'hudson.model.Cause$UserIdCause', shortDescription: 'Started by user TLWHiTeC', userId: 'tlwhitec', userName: 'TLWHiTeC' ], [ _class: 'org.jenkinsci.plugins.workflow.cps.replay.ReplayCause', shortDescription: 'Replayed #3' ] ]
这在Jenkins示例的pipeline语法一节中有记录，其中涵盖了全局变量：https://<jenkins-hostname>/pipeline-syntax/globals#currentBuild你应该仔细阅读这份清单，寻找你感兴趣的原因。有一个 * 实验性的 * 替代方案currentBuild.getBuildCauses(String fqcn)，它已经通过您感兴趣的原因（通过提供的类名）过滤了原因，因此您可以保存自己的迭代。但对未来没有任何保证。它还返回一个列表…触发器类型是hudson.model.Cause子类，例如hudson.model.Cause$UserIdCause是手动触发的（命名模式为<package>.<class>[$<inner-class>]）。请注意，使用currentBuild.getBuildCauses，您只能获得这些对象的JSON转储“fingreprint”，主要是字符串比较或打印。在大多数情况下，这已经足够了，但是如果你想要真实的交易，你需要在沙箱中调用currentBuild.rawBuild.getCauses()**。这将为您提供要使用的实际对象的列表（例如，访问JSON转储中不存在的属性）。
https://<jenkins-hostname>/pipeline-syntax/globals#currentBuild
currentBuild.getBuildCauses(String fqcn)
hudson.model.Cause
hudson.model.Cause$UserIdCause
<package>.<class>[$<inner-class>]
currentBuild.rawBuild.getCauses()
5条答案
按热度按时间vshtjzan1#
您可以使用Rest API获取此信息;下面是一个示例：
http://jenkins.yourdomain.com/job/job_name/build_number/api/json?tree=actions[causes[shortDescription]]&pretty=true
返回
de90aj5v2#
一种解决方案是使用Run Condition Plugin，它可以根据触发器类型运行不同的shell脚本。这不是一个完美的解决方案，但它会做你想要的。
5us2dqdw3#
你也可以使用groovy script。看看我对Jenkins Groovy的回答：什么触发了构建，您可以获取Cause对象，然后检查它是http://javadoc.jenkins-ci.org/hudson/model/Cause.html的哪个子类型
yqhsw0fo4#
在http（s）：//（your-jenkins-server）/jenkins/job/（job-name）/（job-number）的“Build Artifacts”和“Changes”部分（如果有的话）下，您应该会看到这个图标：x1c 0d1x。它旁边的文本应该说明导致构建的原因。
rta7y2nd5#
您可以从任何地方访问所谓的构建原因（即，也在沙盒中）到达
currentBuild.getBuildCauses，这会为您提供当前原因及其一些属性的JSON（类型化，但通常仍然可迭代）列表，例如：这在Jenkins示例的pipeline语法一节中有记录，其中涵盖了全局变量：
https://<jenkins-hostname>/pipeline-syntax/globals#currentBuild你应该仔细阅读这份清单，寻找你感兴趣的原因。有一个 * 实验性的 * 替代方案
currentBuild.getBuildCauses(String fqcn)，它已经通过您感兴趣的原因（通过提供的类名）过滤了原因，因此您可以保存自己的迭代。但对未来没有任何保证。它还返回一个列表…触发器类型是
hudson.model.Cause子类，例如hudson.model.Cause$UserIdCause是手动触发的（命名模式为<package>.<class>[$<inner-class>]）。请注意，使用
currentBuild.getBuildCauses，您只能获得这些对象的JSON转储“fingreprint”，主要是字符串比较或打印。在大多数情况下，这已经足够了，但是如果你想要真实的交易，你需要在沙箱中调用currentBuild.rawBuild.getCauses()**。这将为您提供要使用的实际对象的列表（例如，访问JSON转储中不存在的属性）。