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

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/u011541946/article/details/83278214

这篇开始跟着官网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节点的详细过程。

猜你喜欢

转载自blog.csdn.net/u011541946/article/details/83278214