一.环境变量
环境变量可以看作是pipeline与jenkins交互的媒介，比如可以在pipeline中通过BUILD_NUMBER变量知道构建任务的当前构建次数，环境变量可以分为jenkins内置变量和自定义变量。
1.1 jenkins内置变量
在pipeline执行时，jenkins通过一个名为env的全局变量，将jenkins内置环境变量暴露出来，使用方法如
stage('Example'){
steps{
echo "Running ${env.BUILD_NUMBER} on ${env.JENKINS_URL}" //方法一
echo "Running $env.BUILD_NUMBER on $env.JENKINS_URL" //方法二
}
}
那么env变量都有哪些可用属性呢，通过访问http://localhost:8080/pipeline-syntax/globals#env 来获取完整列表。在列表中，当一个变量被声明为 “For a multibranch project”时 ，就说明只有多分支才会有此变量。如下所示：
下面介绍几个常用到的变量
1) BUILD_NUMBER： 构建号，累加的数字。
2) BUILD_NAME: 多分支pipeline项目支持，当需要根据不同的分支做不同的事情时就会用到，比如将develop分支发布到开发环境，将release分支发布到生产环境。
3) BUILD_URL：当前构建的页面url,如果构建失败，则需要将失败的构建链接放在邮件通知中，这个链接就可以是BUILD_URL。
4) GIT_BRANCH：通过git拉取的源码构建的项目才会有此变量。比如没有分支时值为origin/master, 多分支时为master
小技巧，在调试pipeline时，可以在开始阶段加一句 sh 'printenv' 将env变量的属性打印出来(linux环境)。
1.2自定义pipeline环境变量
当pipeline变量复杂时，就需要自己定义环境变量，使用environment指令，当该指令在pipeline中定义，代表变量作用于整个pipeline; 也可以在stage中定义，代表变量只在该阶段有效。如下所示：
pipeline {
agent any
environment{
CC='clang'
}
stages {
stage('Example'){
environment{
DEBUG_FLAGS='-g'
}
steps{
echo "Running ${CC} AND ${DEBUG_FLAGS} "
}
}
....
打印输出：Running clang AND -g
但是这些变量都不是跨pipeline的，比如pipeline a访问不到pipeline b的变量，如果要共享1.3介绍。
需要注意，environment中定义的变量与env中的变量重名，那么被重名的变量的值会被覆盖掉。
1.3自定义全局环境变量
env中的变量都是jenkins内置的，或者是与具体pipeline相关的，有时候需要定义一些全局的跨pipeline的自定义变量。
Manage Jenkins→Configure System 找到全局属性，点击添加, 如下所示：
steps{
echo "Running ${env.g_name}" //加了自定义全局属性g_name
echo "Running ${CC} AND ${DEBUG_FLAGS} "
}
打印输出如下:Running g_value
二.构建工具
构建是指将源码转换成一个可使用的二进制的过程，这个过程可以包括但不限于这几个环节：下载依赖，编译，打包。构建过程的输出比如一个zip包，我们称为制品。
jenkins只负责执行构建工具提供的命令，本身没有实现任何构建功能。像.net core 的构建需要安装sdk，并查看是否加入PATH变量中，这样就可以在sh或bat步骤里直接使用了。
2.1 tools指令
tools指令能帮助我们自动下载并安装所指定的构建工具，并将其加入PATH变量中，默认支持3种工具：JDK,Maven, Gradle，对于.net构建这三种工具都不用找，一般都事先安装好了.net sdk,所以不需要tools指令去下载构建工具。
