《Jenkins 2.x实践指南》读书笔记-环境变量与构建工具

[TOC]

1. 环境变量

环境变量能够被看做是pipeline与Jenkins交互的媒介。好比，能够在pipeline中经过BUILD_NUMBER变量知道构建任务的当前构建次数。环境变量能够分为Jenkins内置变量和自定义变量。

1.1 内置变量

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

pipeline {
  agent any
  stages {
    stage('Example') {
      steps {
         echo "Running ${env.BUILDNUMBER} on ${env.JENKINS_URL}" # 方法1 推荐
         echo "Running $env.BUILDNUMBER on $env.JENKINS_URL"  # 方法2
         echo "Running ${BUILDNUMBER} on ${JENKINS_URL}"   # 方法3 不推荐，难排查
      }
    }
  }
}

经过访问<Jenkins master的地址>/pipeline-syntax/globals#env来获取完整列表。在列表中，当一个变量被声明为"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中根据分支进行不一样行为的逻辑处理时，须要留意。

1.2 自定义pipeline环境变量

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

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

environment指令能够用在pipeline中定义，做用域就是整个pipeline，当定义在stage阶段，只在当前stage有效。

可是这些变量都不是跨pipeline的，好比pipeline a访问不到pipeline b的变量。在pipeline之间共享变量能够经过参数化pipeline来实现。

环境变量的互相引用：

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

小技巧 ：

1. 在调试pipeline时，能够在pipeline的开始阶段加一句：sh 'printenv'，将env变量的属性值打印出来。这样能够帮助咱们避免很多问题。
2. 自定义变量时，为避免命名冲突，可根据项目或公司加上统一前缀，如__server_name，__就是前缀。

1.3 自定义全局环境变量

定义全局环境变量能够跨pipeline使用。
进入Jenkins→Manage Jenkins→Confiure System找到Global properties→勾选"Environment variables"复选框，单击“Add”按钮，在输入框中输入变量名和变量值便可。

自定义全局环境变量会被加入env属性列表中，因此使用时能够直接用${env.g_name}引用。

2. 构建工具

构建是指将源码转换成一个可以使用的二进制程序的过程。这个过程能够包括但不限于这几个环节：下载依赖、编译、打包。构建过程的输出——好比一个zip包，咱们称之为制品（有些书籍也称之为产出物）。而管理制品的仓库，称为制品库。

2.1 构建工具的选择

对构建工具的选择，还取决于团队对工具自己的接受程度。建议是，团队中同一技术栈的全部项目都使用同一个构建工具。

2.2 tools指令介绍

tools指令能帮助咱们自动下载并安装所指定的构建工具，并将其加入PATH变量中。这样，咱们就能够在sh步骤里直接使用了。但在agent none的状况下不会生效。

tools指令默认支持3种工具：JDK、Maven、Gradle。经过安装插件，tools指令还能够支持更多的工具。接下来，咱们介绍几种经常使用的构建环境的搭建。

2.3 JDK环境搭建

2.3.1 自动安装JDK

进入Manage Jenkins→Global Tool Configuration→JDK页，单击“Add JDK”：

注意

1. 这里须要oracle账户验证。
2. Jenkins不会立刻下载JDK，而是当pipeline使用到时才会直接执行下载操做。

2.3.2 自定义JDK路径

基于安全的考虑，公司的内网机器可能没法直接访问因特网，因此使用自动下载会失败。这时就须要在Jenkins agent上准备JDK，而后在Manage Jenkins→Global Tool Configuration→JDK页中指定名称和JAVA_HOME路径：

注意

1. 使用docker agent或者kubernetes agent时，可以使用agent基础镜像内安装JDK定制成自定义镜像。
2. 能够脚本自动化，即在使用tools安装JDK前，脚本自动提早准备好这个JAVA_HOME的JDK。

2.4 Maven

2.4.1 使用Maven进行构建

Jenkins pipeline的tools指令默认就支持Maven。因此，使用Maven只须要两步。

1. 进入Manage Jenkins→Global Tool Configuration→Maven页，单击“Add Maven”：
   

2. 在Jenkinsfile中指定Maven版本，并使用mvn命令。

2.4.2 使用Managed files设置Maven

Maven默认使用的是其官方仓库，国内下载速度很慢。因此，咱们一般会使用国内的Maven镜像仓库。这时就须要修改 Maven 的配置文件 settings.xml。settings.xml 文件的默认路径为${M2_HOME}/conf/settings.xml。可是，咱们是不可能登陆上Jenkins的机器，而后手动修改这个文件的。
Config File Provider插件能很好地解决这个问题。只须要在Jenkins的界面上填入settings.xml的内容，而后在pipeline中指定settings.xml就能够了。也就是说，对于不一样的pipeline，可使用不一样的settings.xml。
具体实现方法以下：

1. 安装Config File Provider插件。
2. 进入Manage Jenkins页面，就能够看到多出一个“Managed files”菜单。

3. 单击“Managed files”进入，在左侧菜单栏中选择“Add a new Config”，就会看到该插件支持不少种配置文件的格式及方式，
   

4. 选择“Global Maven settings.xml”选项。由于咱们的设置是全局的。填写“ID”字段，Jenkins pipeline会引用此变量名。假如使用的ID为maven-global-settings。
5. 在编辑页将自定义的Maven settings.xml的内容粘贴到“Content”字段中，

6. 在Jenkins pipeline中使用的方法以下：

configFileProvider([configFile(fileId: "maven-global-settings", variable: "MAVEN_GLOBAL_ENV")]) {
    sh "mvn -s $MAVEN_GLOBAL_ENV clean install"
}

2.5 Go语言环境搭建

Jenkins支持Golang的构建，只须要如下几步。

1. 安装Go插件。
2. 进入Manage Jenkins→Global Tool Configuration→Go页

3. 在pipeline中加入tools部分。

pipeline {
    agent none
    environment {
        GOPATH = "${env.WORKSPACE}/"
    }
    tools {
        go 'go1.10'
    }    
    stages {
        stage('build') {
            steps {
                sh "go build"
            }
        }
    }
}

此时，在环境变量中会增长一个GOROOT变量。

4. 设置GOPATH。了解Go语言开发的读者都会知道，编译时须要设置GOPATH环境变量。直接在environment指令中添加就能够了。

2.6 Python环境搭建

Python环境很容易产生Python版本冲突、第三方库冲突等问题。因此，Python开发一般会进行工程级别的环境隔离，也就是每一个Python工程使用一个Python环境。

在Jenkins环境下，咱们使用Pyenv Pipeline插件能够轻松地实现。
首先，准备Python基础环境。

1. 在Jenkins机器上安装python、pip、virtualenv。
   • pip：Python的包管理工具。
   • virtualenv：Python中的虚拟环境管理工具。
2. 安装Pyenv Pipeline插件。
   而后，在pipeline中使用Pyenv Pipeline插件提供的withPythonEnv方法。

withPythonEnv("/usr/bin/python") {
    sh "python --version"
}

withPythonEnv方法会根据第一个参数——可执行python路径——在当前工做空间下建立一个virtualenv环境。
withPythonEnv方法的第二个参数是一个闭包。闭包内的代码就执行在新建的virtualenv环境下。

3. 利用环境变量支持更多的构建工具

不是全部的构建工具都须要安装相应的Jenkins插件才可使用。
平时，开发人员在搭建开发环境时作的就是：首先在机器上安装好构建工具，而后将这个构建工具所在目录加入PATH环境变量中。
若是想让Jenkins支持更多的构建工具，也是一样的作法：在Jenkins agent上安装构建工具，并记录下它的可执行命令的目录，而后在须要使用此命令的Jenkins pipeline的PATH环境变量中加入该可执行命令的目录。示例以下：

pipeline {
    agent none
    environment {
        PATH = "/usr/local/customtool/bin:$PATH"
    }
    stages {
        stage('build') {
            steps {
                sh "customtool build"
            }
        }
    }
}

还能够有另外一种写法：

pipeline {
    agent none
    environment {
        CUSTOM_TOOL_HOME = "/usr/local/customtool/bin"
    }
    stages {
        stage('build') {
            steps {
                sh "${CUSTOM_TOOL_HOME}/customtool build"
            }
        }
    }
}

4. 利用tools做用域实现多版本编译

在实际工做中，有时须要对同一份源码使用多个版本的编译器进行编译。tools指令除了支持pipeline做用域，还支持stage做用域。因此，咱们能够在同一个pipeline中实现多版本编译。代码以下：

pipeline {
    agent none
    stages {
        stage('build with jdk-10.0.2') {
            tools {
                jdk "jdk-10.0.2"
            }
            steps {
                sh "printenv"
            }
        }
        stage('build with jdk-9.0.4') {
            tools {
                jdk "jdk-9.0.4"
            }
            steps {
                sh "printenv"
            }
        }       
    }
}

在打印出来的日志中，会发现每一个stage下的JAVA_HOME变量的值都不同。

参考资料：
[1] 《Jenkins 2.x实战指南》
[2] https://jenkins.io/zh/doc/book/pipeline/syntax/
[3] https://jenkins.io/zh/doc/pipeline/steps/