jenkins 环境变量与构建工具(7)
一.环境变量
环境变量可以看作是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指令去下载构建工具。