Jenkins高级篇之Pipeline语法篇-4-Declarative Pipeline语法-agent

这篇开始跟着官网Pipeline文章来具体学习Pipeline语法知识。我们先从Declarative 模式开始，当然，以后我个人主推使用这个模式，前面已经说了原因。这里再说下Declarative的特点，Declarative Pipeline是Jenkins Pipeline 的一个相对较新的补充， 它在Pipeline子系统之上提出了一种更为简化和有意义的语法。我看到有人把Declarative这个单词，翻译成声明，这没毛病，我还是采用英文，不去翻译这个单词。

 

1.Pipeline语法引用官网地址

接下来的Pipeline语法和部分练习代码都来着官网，地址是：https://jenkins.io/doc/book/pipeline/syntax/

我个人认为官网的文章组织不适合初学者，有些Pipeline代码穿插了很多docker的知识进去，但是我们没有学docker，这样给初学者造成很大的学习压力和负担。

 

2.Declarative Pipeline概述

所有有效的Declarative Pipeline必须包含在一个pipeline块内，例如：

pipeline {

    /* insert Declarative Pipeline here */

}

Declarative Pipeline中有效的基本语句和表达式遵循与Groovy语法相同的规则 ，但有以下例外：

• Pipeline的顶层必须是块，具体来说是：pipeline { }
• 没有分号作为语句分隔符。每个声明必须在自己的一行
• 块只能包含章节， 指令，步骤或赋值语句。
• 属性引用语句被视为无参数方法调用。所以例如，input被视为input（）

第一点，前面文章解释过，就是一个代码块范围的意思，很好理解。第二个以后可能经常会犯这个，分号写了也是多余的。Groovy代码还可以写分号，Jenkins Pipeline代码就不需要，每行只写一个声明语句块或者调用方法语句。第三点，只能包含Sections, Directives, Steps或者赋值语句，其中的Sections 和Directives后面语法会解释。指令和步骤，前面文章我介绍过，例如steps, stage, agent等。最后一句话，我也不确定，没有理解透彻。

3. sections

Declarative Pipeline 代码中的Sections指的是必须包含一个或者多个指令或者步骤的代码区域块。Sections不是一个关键字或者指令，只是一个逻辑概念。

4.agent

该agent部分指定整个Pipeline或特定阶段将在Jenkins环境中执行的位置，具体取决于该agent 部分的放置位置。该部分必须在pipeline块内的顶层定义 ，但阶段级使用是可选的。

简单来说，agent部分主要作用就是告诉Jenkins，选择那台节点机器去执行Pipeline代码。这个指令是必须要有的，也就在你顶层pipeline {…}的下一层，必须要有一个agent{…},agent这个指令对应的多个可选参数，本篇文章会一一介绍。这里注意一点，在具体某一个stage {…}里面也可以使用agent指令。这种用法不多，一般我们在顶层使用agent，这样，接下来的全部stage都在一个agent机器下执行代码。

为了支持Pipeline作者可能拥有的各种用例，该agent部分支持几种不同类型的参数。这些参数可以应用于pipeline块的顶层，也可以应用在每个stage指令内。

为了支持写Pipeline代码的人可能遇到的各种用例场景，agent部分支持几种不同类型的参数。这些参数可以应用于pipeline块的顶层，也可以应用在每个stage指令内。

参数1：any

作用：在任何可用的代理上执行Pipeline或stage。

代码示例

pipeline {
    agent any
}

上面这种是最简单的，如果你Jenkins平台环境只有一个master，那么这种写法就最省事情.

参数2：none

作用：当在pipeline块的顶层应用时，将不会为整个Pipeline运行分配全局代理，并且每个stage部分将需要包含其自己的agent部分。

代码示例：

pipeline {
    agent none
    stages {
        stage(‘Build’){
	    agent {
               label ‘具体的节点名称’
            }
        }
    }
}

参数3：label

作用：使用提供的标签在Jenkins环境中可用的代理机器上执行Pipeline或stage内执行。

代码示例：

pipeline {
    agent {
       label ‘具体一个节点label名称’
    }
}

参数4：node

作用：和上面label功能类似，但是node运行其他选项，例如customWorkspace

代码示例：

pipeline {
    agent {
        node {
            label ‘xxx-agent-机器’
            customWorkspace "${env.JOB_NAME}/${env.BUILD_NUMBER}"
        }
    }
}

目前来说，这种node类型的agent代码块，在实际工作中使用可能是最多的一个场景。我建议你分别测试下有和没有customWorkspace的区别，前提你要有自己Jenkins环境，能找到"${env.JOB_NAME}/${env.BUILD_NUMBER}"这个具体效果。

其实agent相关的还有两个可选参数，分别是docker和dockerfile。目前，我不想把docker加入进来，给我们学习Pipeline增加复杂度。但是docker又是很火的一个技术栈，以后如果你项目中需要docker，请去官网找到这两个参数的基本使用介绍。

如果你认真花了时间在前面两篇，那么你就知道如何测试上面的每一段代码。你可以在Jenkins UI上贴上面代码，也可以写入jenkinsfile，走github拉去代码。下面，我写一个测试代码，结合上面node的代码，放在Jenkins UI上进行测试。

代码如下：

pipeline {
    agent {
        node {
            label ‘xxx-agent-机器’
            customWorkspace "${env.JOB_NAME}/${env.BUILD_NUMBER}"
        }
   }
   stages {
       stage (‘Build’) {
           bat “dir” // 如果jenkins安装在windows并执行这部分代码
           sh “pwd”  //这个是Linux的执行
       }

       stage (‘Test’) {
           bat “dir” // 如果jenkins安装在windows并执行这部分代码
           sh “echo ${JAVA_HOME}”  //这个是Linux的执行
       }

   }
}

拷贝上面代码在Jenkins job的pipeline设置页面，保存，启动测试。

 

注意 :以上代码的agent中label的值，如果你不会配置在Jenkins上添加节点，那么你就改成agent any来跳过这部分，后面我会写一篇文章介绍，如何在Jenkins上添加一个agent节点的详细过程。