如何在 Jenkins 中使用 Groovy PostBuild 永久更新全局环境变量并在其他后续构建中使用它?
How can I update a global Environment Variable using Groovy PostBuild in Jenkins permanently and use it in other subsequent builds?
我有一个要求,即仅当之前的类似事件结束时我才想创建一个立即服务事件。我正在使用 Jenkins 自由式作业。我采取的方法如下:-
- 创建一个全局环境变量来存储事件编号并设置一个默认值。
- 检查上游作业中事件的状态并将状态传递给下游作业。
- 在下游作业中,如果事件仍处于打开状态,则什么也不做。如果是Closed/Resolved,创建
另一个具有一些定义描述的事件。
- 用当前事件编号更新全局环境变量。并永久保存。
- 检查更新的事件编号的状态(通过访问全局环境变量)然后
在后续构建过程中遵循相同的过程。
到目前为止,我已经通过使用各种插件实现了第3步。为了实现第 4 步,我正在使用 groovy post-build 插件,这样我就可以永久更新全局环境变量,以便它在我的下一个构建中可用,这样我就可以检查状态在创建新的事件之前。
我想出了一个代码,但它似乎并没有永久更新变量(通过在后续构建中打印变量来验证)。根据我的要求,该脚本还有其他部分,但 SNOW_INC 是我想要永久更新的全局变量,直到下一次构建。
import groovy.json.JsonSlurper
import hudson.model.*
def workspace = manager.build.getEnvVars()["WORKSPACE"]
def console = manager.listener.logger.&println
build = Thread.currentThread().executable
String jobName = build.project.getName()
job = Hudson.instance.getJob(jobName)
my_env_var = job.getLastBuild().getEnvironment()["SNOW_INC"]
console(my_env_var)
try{
def inputFile = new File(workspace, 'response.json')
if (inputFile != null){
JsonSlurper slurper = new JsonSlurper()
parsedJson = slurper.parse(inputFile)
String number= parsedJson.result.number
console("${number}")
System.setProperty("hudson.model.ParametersAction.safeParameters", "INC_NUMBER")
manager.build.addAction(
new ParametersAction(
new StringParameterValue("INC_NUMBER", "${number}")
)
)
manager.build.addAction(
new ParametersAction(
new StringParameterValue("SNOW_INC", "${number}")
)
)
console("Environment Variable set")
}
} catch (Exception e){
println("response.json file was not ")
}
如有任何帮助,我们将不胜感激!
总之,几天就找到了解决办法。因此,为了修改可在任何作业或任何构建中使用的全局环境变量,如下所示(这在 Groovy Postbuild 中使用,如前所述):
nodes = Jenkins.getInstance().getGlobalNodeProperties()
nodes.getAll(hudson.slaves.EnvironmentVariablesNodeProperty.class)
if ( nodes.size() != 1 ) {
console("error: unexpected number of environment variable containers: "
+ nodes.size()
+ " expected: 1")
} else {
envVars= nodes.get(0).getEnvVars()
envVars.put("SNOW_INC", "${number}")
Jenkins.getInstance().save()
}
因此,在创建新事件的任何 运行 之后,我将使用更新后的数字更新环境变量“SNOW_INC”。然后在另一个工作中使用它来根据场景验证该事件是否打开。
很有魅力!
我有一个要求,即仅当之前的类似事件结束时我才想创建一个立即服务事件。我正在使用 Jenkins 自由式作业。我采取的方法如下:-
- 创建一个全局环境变量来存储事件编号并设置一个默认值。
- 检查上游作业中事件的状态并将状态传递给下游作业。
- 在下游作业中,如果事件仍处于打开状态,则什么也不做。如果是Closed/Resolved,创建 另一个具有一些定义描述的事件。
- 用当前事件编号更新全局环境变量。并永久保存。
- 检查更新的事件编号的状态(通过访问全局环境变量)然后 在后续构建过程中遵循相同的过程。
到目前为止,我已经通过使用各种插件实现了第3步。为了实现第 4 步,我正在使用 groovy post-build 插件,这样我就可以永久更新全局环境变量,以便它在我的下一个构建中可用,这样我就可以检查状态在创建新的事件之前。 我想出了一个代码,但它似乎并没有永久更新变量(通过在后续构建中打印变量来验证)。根据我的要求,该脚本还有其他部分,但 SNOW_INC 是我想要永久更新的全局变量,直到下一次构建。
import groovy.json.JsonSlurper
import hudson.model.*
def workspace = manager.build.getEnvVars()["WORKSPACE"]
def console = manager.listener.logger.&println
build = Thread.currentThread().executable
String jobName = build.project.getName()
job = Hudson.instance.getJob(jobName)
my_env_var = job.getLastBuild().getEnvironment()["SNOW_INC"]
console(my_env_var)
try{
def inputFile = new File(workspace, 'response.json')
if (inputFile != null){
JsonSlurper slurper = new JsonSlurper()
parsedJson = slurper.parse(inputFile)
String number= parsedJson.result.number
console("${number}")
System.setProperty("hudson.model.ParametersAction.safeParameters", "INC_NUMBER")
manager.build.addAction(
new ParametersAction(
new StringParameterValue("INC_NUMBER", "${number}")
)
)
manager.build.addAction(
new ParametersAction(
new StringParameterValue("SNOW_INC", "${number}")
)
)
console("Environment Variable set")
}
} catch (Exception e){
println("response.json file was not ")
}
如有任何帮助,我们将不胜感激!
总之,几天就找到了解决办法。因此,为了修改可在任何作业或任何构建中使用的全局环境变量,如下所示(这在 Groovy Postbuild 中使用,如前所述):
nodes = Jenkins.getInstance().getGlobalNodeProperties()
nodes.getAll(hudson.slaves.EnvironmentVariablesNodeProperty.class)
if ( nodes.size() != 1 ) {
console("error: unexpected number of environment variable containers: "
+ nodes.size()
+ " expected: 1")
} else {
envVars= nodes.get(0).getEnvVars()
envVars.put("SNOW_INC", "${number}")
Jenkins.getInstance().save()
}
因此,在创建新事件的任何 运行 之后,我将使用更新后的数字更新环境变量“SNOW_INC”。然后在另一个工作中使用它来根据场景验证该事件是否打开。 很有魅力!