查看“Jenkins环境变量”的源代码

环境变量可以被看作是pipeline与Jenkins交互的媒介。比如，可以在pipeline中通过BUILD_NUMBER变量知道构建任务的当前构建次数。环境变量可以分为Jenkins内置变量和自定义变量。接下来我们分别讨论。

=== Jenkins内置变量 ===

在pipeline执行时，Jenkins通过一个名为env的全局变量，将Jenkins内置环境变量暴露出来。其使用方法有多种，示例如下：

 pipeline {
    agent any
    stages {
        stage('Example') {
            step {
                echo "running ${env.BUILD_NUMBER} on ${env.JENINS_URL}"
                echo "running $env.BUILD_NUMBER on $env.JENKINS_URL"
                echo "running ${PBUILD_NUMBER}on ${JENKINS_URL}"
            }
        }
    }
 }

默认env的属性可以直接在pipeline中引用。所以，以上方法都是合法的。但是不推荐方法三，因为出现变量冲突时，非常难查问题。

那么，env变量都有哪些可用属性呢？通过访问＜Jenkins master的地址>/pipeline-syntax/globalsenv来获取完整列表。在列表中，当一个变量被声明为“For a multibranch project”时，代表只有多分支项目才会有此变量。

下面我们简单介绍几个在实际工作中经常用到的变量。

• BUILD_NUMBER：构建号，累加的数字。在打包时，它可作为制品名称的一部分，比如server-2.jar。
• BRANCH_NAME：多分支pipeline项目支持。当需要根据不同的分支做不同的事情时就会用到，比如通过代码将release分支发布到生产环境中、master分支发布到测试环境中。
• BUILD_URL：当前构建的页面URL。如果构建失败，则需要将失败的构建链接放在邮件通知中，这个链接就可以是BUILD_URL。
• GIT_BRANCH：通过git拉取的源码构建的项目才会有此变量。

在使用env变量时，需要注意不同类型的项目，env变量所包含的属性及其值是不一样的。比如普通pipeline任务中的GIT BRANCH变量的值为origin/master，而在多分支pipeline任务中GIT BRANCH变量的值为master。

所以，在pipeline中根据分支进行不同行为的逻辑处理时，需要留意。

小技巧：在调试pipeline时，可以在pipeline的开始阶段加一句：sh'printenv'，将env变量的属性值打印出来。这样可以帮助我们避免不少问题。

=== 自定义pipeline环境变量 ===
当pipeline变得复杂时，我们就会有定义自己的环境变量的需求。声明式pipeline提供了environment指令，方便自定义变量。比如：

 pipeline {
    agent any 
    environment {
        CC = 'clang'
    }
    stages {
        stage('Example') {
            environment {
                DEBUG_FLAGES = '-g'
            }
         stages {
             ssh "${CC} ${DEBUG_FLAGS}"
             ssh 'printenv'
         }
        }
    }
 }

另外，environment指令可以在pipeline中定义，代表变量作用域为整个pipeline；也可以在stage中定义，代表变量只在该阶段有效。
但是这些变量都不是跨pipeline的，比如pipeline a访问不到pipeline b的变量。在pipeline之间共享变量可以通过参数化pipeline来实现。

在实际工作中，还会遇到一个环境变量引用另一个环境变量的情况。在environment中可以这样定义：

 environment {
    __server_name = 'mail-server'
    __version == "${BUILD_NUMBER}"
    __artifact_name = "$(__server_name)-${__version.jar}"
 }

值得注意的是，如果在environment中定义的变量与env中的变量重名，那么被重名的变量的值会被覆盖掉。比如在environment中定义PATH变量（PATH也是env中的一个变量）。

 environment {
    PATH = "invalid path"
 }

在执行sh指令时，我们看到无法在系统上执行

 [Pipeline] sh
 [maven-pipeline2] Running shell scripts
 nohup: failed to run command 'sh' : NO such file or directory

小技巧：为避免变量名冲突，读者可根据所在公司的实际情况，在变量名前加上前缀，比如__server_name，__就是前缀。
=== 自定义全局环境变量 ===
env中的变量都是Jenkins内置的，或者是与具体pipeline相关的。有时候，我们需要定义一些全局的跨pipeline的自定义变量。
进入Manage Jenkins→Configure System→Global properties页，勾选“Environment variables”复选框，单击“Add”按钮，在输入框中输入变量名和变量值即可.

通过单击“Add”按钮，还可以添加多个全局环境变量。
自定义全局环境变量会被加入 env 属性列表中，所以，使用自定义全局环境变量与使用Jenkins内置变量的方法无异：${env.g name}。