将Jenkins构建参数传递给管道节点

本文介绍了将Jenkins构建参数传递给管道节点的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我创建了一个新的Jenkins管道. (当前)使用名为VAR_A的单个布尔选项对管道进行参数化.我的管道脚本是:

I created a new Jenkins pipeline. The pipeline is (currently) parametrized with a single boolean option named VAR_A. My pipeline script is:

node ('windows') { echo "$VAR_A" bat 'env' }

当我在选中VAR_A的情况下手动构建项目时，将按预期回显"true".但是，环境变量列表不显示VAR_A=true.

When I manually build the project with VAR_A checked, "true" is echoed, as expected. The list of environment variables, however, does not show VAR_A=true.

如果我将呼叫包装在withEnv块中，我就能得到env来显示VAR_A:

I am able to get env to show VAR_A if I wrap the call in a withEnv block:

node ('windows') { echo "$VAR_A" withEnv(["VAR_A=$VAR_A"]) { bat 'env' } }

我将提供比这更多的参数，因此不需要单独指定每个参数. 是否可以将所有构建参数传输到节点的环境?

I will more parameters than this, so specifying each parameter individually is not desired. Is there a way to transfer all build parameters to a node's environment?

推荐答案

要点是，在管道脚本中，作业参数不会像常规作业一样自动注入到环境中.每个参数都成为管道脚本的变量 binding .因此，您可以直接按名称访问它们.

The point is that in Pipeline scripts the job parameters are not injected into the environment automatically as for regular jobs. Each parameter becomes a variable of the Pipeline script binding. Therefore you can access them directly by name.

在您的示例echo "$VAR_A"中，变量替换是由groovy在脚本上下文中执行的(请参阅有关字符串插值的常用文档).这就是为什么您在bat输出中看不到它的原因.

In your example echo "$VAR_A" variable substitution is performed by groovy in the context of your script (see Groovy doc on strings interpolation). That's why you don't see it in the bat output.

对于要注入的每个参数，您需要添加以下行: env.VAR_A = VAR_A在脚本开头.它可以在node块之外，因为env在整个脚本中是全局的.

For each parameter you want to inject you need to add a line like this: env.VAR_A = VAR_A in the beginning of your script. It can be outside of node block because env is global within the whole script.

或者，有一种方法可以将所有脚本变量(包括参数，甚至是管道内置变量)(即steps)添加到环境中.不幸的是，它需要一些白名单才能在沙箱中运行:

Alternatively there is a way to add all the script vars, including parameters and even Pipeline built-in vars i.e. steps into the environment. Unfortunately it will require some whitelisting to run in a sandbox:

@NonCPS def populateEnv(){ binding.variables.each{k,v -> env."$k" = "$v"} } populateEnv()

示例: VAR_A 是一个参数. 脚本主体:

Example: VAR_A is a parameter. Script body:

def AAAA = 1 // such a definition doesn't put variable in the binding BBBB = 2 // creates a binding variable. Absolutely the same behavior as for a job parameter. @NonCPS def populateEnv(){ binding.variables.each{k,v -> env."$k" = "$v"} } populateEnv() // at this point injection happens CCCC = 3 // created after the injection hence it won't appear in env. node ('windows') { bat 'env' }

在bat输出中，您将找到VAR_A和BBBB.

In the bat output you will find VAR_A and BBBB.

除非您的工作中定义了数十个参数，否则首选env.VAR_A = VAR_A方法，因为它更简单，直接并且不需要批准.

IMO unless your job has tens of parameters defined env.VAR_A = VAR_A approach is preferred as more simple, straightforward, and requiring no approvals.