在 Jenkins Pipeline 中引用变量
- 在
Jenkins pipeline 中，环境变量可以通过 env 前缀来引用。例如，如果在 environment 阶段定义了一个环境变量 APP_VERSION，可以在 stages 的步骤中这样引用：
pipeline {
agent any
environment {
APP_VERSION = "1.0.0"
}
stages {
stage('ExampleStage') {
steps {
echo "应用程序版本是：${env.APP_VERSION}"
}
}
}
}
- 对于在
script 块内使用 def 定义的局部变量，直接使用变量名来引用。例如：
pipeline {
agent any
stages {
stage('ExampleStage') {
steps {
script {
def localVar = "这是一个局部变量"
echo localVar
}
}
}
}
}
- 如果
pipeline 接受参数（例如通过构建参数传入），可以通过 params 来引用这些参数变量。假设在构建时可以传入一个参数 BRANCH_NAME，在 pipeline 中可以这样使用：
pipeline {
agent any
parameters {
string(name: 'BRANCH_NAME', defaultValue: 'master', description: '请选择分支名称')
}
stages {
stage('ExampleStage') {
steps {
echo "构建的分支是：${params.BRANCH_NAME}"
}
}
}
}
pipeline（groovy）变量与shell变量相混淆
- 在
sh 步骤中，当传递给 shell 脚本的内容使用单引号时，Groovy 变量不会被替换，而使用双引号时会进行替换。这是一个关键的点来避免混淆。例如：
pipeline {
agent any
stages {
stage('ExampleStage') {
steps {
def myVar = "变量值"
// 使用单引号，myVar不会被替换，在shell脚本中会被当作字符串'$myVar'
sh 'echo $myVar'
// 使用双引号，myVar会被替换为其值
sh "echo $myVar"
}
}
}
}
- 在这个例子中，第一个
sh 步骤中的 $myVar 在 shell 脚本执行时会被当作普通字符串，因为单引号阻止了 Groovy 对变量的替换。而第二个 sh 步骤中，$myVar 会被替换为 Groovy 中定义的变量 myVar 的值。
- 使用
${} 明确变量引用（在双引号内）：
- 为了更清晰地在
sh 步骤（双引号内）引用 Groovy 变量，推荐使用 ${} 语法。例如：
pipeline {
agent any
stages {
stage('ExampleStage') {
steps {
def myVar = "变量值"
sh "echo ${myVar}"
}
}
}
- 这种方式使得变量引用更加明确，尤其在复杂的字符串拼接和变量引用场景下，可以减少混淆的可能性。
- 对
shell 脚本中的变量使用不同的命名风格：
- 如果需要在
shell 脚本中定义变量，可以采用与 Groovy 变量不同的命名风格。例如，在 Groovy 中使用驼峰命名法（如 myVariable），在 shell 脚本中使用全大写或全小写并使用下划线分隔（如 MY_VARIABLE 或 my_variable）。例如：
pipeline {
agent any
stages {
stage('ExampleStage') {
steps {
sh '''
# 在shell脚本中定义变量，使用不同的命名风格
MY_VARIABLE="这是一个shell变量"
echo $MY_VARIABLE
'''
}
}
}
}
全局变量与局部变量
- 全局变量的定义和访问方式
- 在
Jenkins pipeline中，如果没有使用env前缀定义变量，在某些情况下它可能看起来像一个全局变量，但实际上这可能会导致一些潜在的问题。
- 例如，在
script块外直接定义变量：
pipeline {
agent any
def globalVar = "这看起来像全局变量"
stages {
stage('ExampleStage') {
steps {
echo globalVar
}
}
}
}
- 在这个例子中，变量
globalVar可以在pipeline的stages部分被访问和使用。这是因为Groovy允许在script块外定义变量，并且在同一个Jenkinsfile的范围内可以访问这些变量。然而，这种方式定义的变量与通过env定义的环境变量有区别。
- 与环境变量的区别和潜在问题
- 虽然在
script块外定义的变量在Jenkinsfile的主要部分（如stages等）可以访问，但它的作用域并没有像环境变量那样扩展到整个Jenkins执行环境。例如，如果这个pipeline在不同的节点上执行，或者在pipeline中启动了一个新的agent（比如在docker容器代理等情况下），这种方式定义的变量可能无法像环境变量一样被正确传递和访问。
- 环境变量（通过
env定义）是Jenkins执行环境中明确的全局变量概念，它们可以被pipeline中的所有步骤、阶段以及可能的子pipeline等共享。而不使用env定义的变量，其共享性和可见性更像是在Groovy脚本的范围内，对于外部工具、插件或者其他可能的Jenkins扩展机制来说，这些变量可能不被识别为真正的全局变量。
Jenkins的环境变量可以在系统配置层面、节点配置层面或者通过插件进行管理和持久化。例如，可以在Jenkins的全局配置中设置一些默认的环境变量，这些变量会在所有的pipeline中生效（如果没有被局部覆盖）。但对于非env定义的变量，这种持久化和配置管理的机制通常不适用，它们更多地依赖于Jenkinsfile本身的代码逻辑和执行流程。
所以，虽然在某些简单的Jenkinsfile场景下，不使用env定义的变量可能看起来可以像全局变量一样使用，但从Jenkins的规范和更复杂的应用场景考虑，建议使用env来定义真正的全局（环境）变量，以确保变量在整个Jenkins执行环境中的一致性、可共享性和可管理性。
