标签：pipeline Pipeline 笔记 参数 agent 流水线 jenkins stage
一、jenkins pipeline
1.jenkins 什么是Pipeline
要实现CD，先要实现CI。CD Pipeline就是一个代码文件，里面把你项目业务场景都通过Groovy代码和Pipeline语法实现，一个一个业务串联起来，全部实现自动化，从代码仓库到生产环境完成部署的自动化流水线。这个过程就是一个典型的CD Pipeline。
官网建议我们把Pipeline代码放在一个名称为Jenkinsfile的文本文件中，并且把这个文件放在项目代码的根目录，采用版本管理工具管理。
2.Pipeline代码分类和两者区别
一个Jenkinsfile或者一个Pipeline代码文件，我们可以使用两个脚本模式去写代码，这两种分类叫：Declarative Pipeline 和 Scripted Pipeline.
Declarative相对于Scripted有两个优点。
1）、第一个是提供更丰富的语法功能；
2）、第二个是写出来的脚本可读性和维护性更好；
3.选择使用Pipeline的原因
Jenkins是一个非常著名的CI服务器平台，支持很多不同第三方（插件的形式）集成自动化测试。
Jenkins UI 配置已经满足不了这么复杂的自动化需求，加入Pipeline功能之后，Jenkins 表现更强大。
Pipeline主要有一下特点
Code代码：Pipeline是用代码去实现，并且支持check in到代码仓库，这样项目团队人员就可以修改，更新Pipeline脚本代码，支持代码迭代。
Durable耐用：Pipeline支持在Jenkins master(主节点)上计划之内或计划外的重启下也能使用。
Pausable可暂停：Pipeline支持可选的停止和恢复或者等待批准之后再跑Pipeline代码。
Versatile丰富功能：Pipeline支持复杂和实时的CD需求，包括循环，拉取代码，和并行执行的能力。
Extensible可扩展性：Pipeline支持DSL的自定义插件扩展和支持和其他插件的集成。
二、jenkins pipeline 流程图
第1步.开发(IDE)提交代码到项目仓库服务器（gitlab）;
第2步.jenkins开始执行Pipeline代码文件，开始从(gitlab)仓库git clone代码;
第3步.jenkins启动Pipeline里面第一个stage(阶段);
第4步.图里面第一个Stage从仓库检出（Checkout）代码;
第5步.接着进入第二Stage构建（Build）检出的代码;
第6步.然后进入测试（Test）的阶段，执行各种自动化测试验证;
第7步.然后测试结束，到运维的部署（Deploy）阶段;
第8步.部署结束，输出报告，整个自动化流程工作完成;
等待触发构建，开始重复下一轮1到8步骤。
三、Pipeline概念基础
四、Declarative Pipeline（声明式流水线）概述
所有有效的Declarative Pipeline必须包含在一个pipeline块内，例如：
pipeline {
/* insert Declarative Pipeline here */
}
Declarative Pipeline中有效的基本语句和表达式遵循与Groovy语法相同的规则 ，但有以下例外：
Pipeline的顶层必须是块，具体来说是：pipeline { }
没有分号作为语句分隔符。每个声明必须在自己的一行
块只能包含章节， 指令，步骤或赋值语句。
属性引用语句被视为无参数方法调用。所以例如，input被视为input（）
Groovy代码还可以写分号，Jenkins Pipeline代码就不需要，每行只写一个声明语句块或者调用方法语句。
1、Sections（节段）
Declarative Pipeline（声明式流水线） 代码中的Sections指的是必须包含一个或者多个指令或者步骤的代码区域块。Sections不是一个关键字或者指令，只是一个逻辑概念。
1）.Parameters-agent
| Required（必需的） | Yes | |
|---|---|---|
| Parameters（参数） | Described below（详情如下） | |
| Allowed（允许） | In the top-level pipeline block and each stage block（在顶级管道块和每个阶段块中） |
agent 部分指定了整个流水线或特定的部分，将会在jenkins环境中执行的位置，该部分不许再pipeline的顶层定义，但是stage级别的使用是可选择的，也可以使用在stage级。
简单来说，agent部分主要作用就是告诉Jenkins，选择那台节点机器去执行Pipeline代码。这个指令是必须要有的，也就在你顶层pipeline {…}的下一层，必须要有一个agent{…}
为了支持写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内执行。
定义方式为：一个字符串。该标签用于运行流水线或个别的 stage。
该参数对 node, docker 和 dockerfile 可用, node要求必须选择该选项。
//代码示例：
pipeline {
agent {
label "具体一个节点label名称"
}
}
参数4:node
//作用：和上面label功能类似，但是node运行其他选项，例如customWorkspace
//代码示例：
pipeline {
agent {
node {
label "xxx-agent-机器"
customWorkspace "${env.JOB_NAME}/${env.BUILD_NUMBER}"
}
}
}
目前来说，这种node类型的agent代码块，在实际工作中使用可能是最多的一个场景。
agent { node {
label 'labelName'
}
}
//和 agent { label 'labelName' } 一样, 但是 node 允许额外的选项 (比如 customWorkspace )
参数5:customWorkspace
一个字符串,在自定义工作区运行应用了 agent 的流水线或个别的 stage, 而不是默认值。 它既可以是一个相对路径, 在这种情况下，自定义工作区会存在于节点工作区根目录下, 或者一个绝对路径。该参数对 node, docker 和 dockerfile 有用比如:
agent {
node {
label 'my-defined-label'
customWorkspace '/some/other/path'
}
}
下面，我写一个测试代码，结合上面node的代码，放在Jenkins UI上进行测试。代码如下：
pipeline{
agent{
label '224.86'//构建节点机器
}
stages{
stage('pwd') {
steps {
bat 'pwd'
}
}
stage('dir') {
steps {
bat 'dir'
}
}
stage('JAVA_HOME'){
steps{
sh "echo ${JAVA_HOME}"
}
}
}
}
拷贝上面代码在Jenkins job的pipeline设置页面，保存，启动测试。
参数6:docker
使用给定的容器执行流水线或阶段。该容器将在预置的 node上，或在匹配可选定义的label 参数上，动态的供应来接受基于Docker的流水线。 docker 也可以选择的接受 args 参数，该参数可能包含直接传递到 docker run 调用的参数, 以及 alwaysPull 选项, 该选项强制 docker pull ，即使镜像名称已经存在。
agent { docker 'maven:3-alpine' } //或
agent {
docker {
image 'maven:3-alpine'
label 'my-defined-label'
args '-v /tmp:/tmp'
}
}
参数7:dockerfile
执行流水线或阶段, 使用从源代码库包含的 Dockerfile 构建的容器。为了使用该选项， Jenkinsfile 必须从多个分支流水线中加载, 或者加载 "Pipeline from SCM." 通常，这是源代码仓库的根目录下的 Dockerfile : agent { dockerfile true }. 如果在另一个目录下构建 Dockerfile , 使用 dir 选项: agent { dockerfile {dir 'someSubDir' } }。如果 Dockerfile 有另一个名称, 你可以使用 filename 选项指定该文件名。你可以传递额外的参数到 docker build ... 使用 additionalBuildArgs 选项提交, 比如
agent { dockerfile {additionalBuildArgs '--build-arg foo=bar' } }
//例如, 一个带有 build/Dockerfile.build 的仓库,期望一个构建参数 version:
agent {
// Equivalent to "docker build -f Dockerfile.build --build-arg version=1.0.2 ./build/
dockerfile {
filename 'Dockerfile.build'
dir 'build'
label 'my-defined-label'
additionalBuildArgs '--build-arg version=1.0.2'
}
}
2）.Parameters-post
可以根据pipeline的状态来执行一些操作，定义Pipeline或stage运行结束时的操作。post-condition块支持post部件：always，changed，failure，success，unstable，和aborted。这些块允许在Pipeline或stage运行结束时执行步骤，具体取决于Pipeline的状态。按照惯例, post 部分应该放在流水线的底部。
| Required（必需的） | NO |
|---|---|
| Parameters（参数） | NONE |
| Allowed（允许） | In the top-level pipeline block and each stage block（在顶级管道块和每个阶段块中） |
| post-condition（情况） | |
|---|---|
| always | 运行，无论Pipeline运行的完成状态如何 |
| changed | 只有当前Pipeline运行的状态与先前完成的Pipeline的状态不同时，才能运行 |
| failure | 仅当当前Pipeline处于“失败”状态时才运行，通常在Web UI中用红色指示表示 |
| success | 仅当当前Pipeline具有“成功”状态时才运行，通常在具有蓝色或绿色指示的Web UI中表示 |
| unstable | 只有当前Pipeline具有“不稳定”状态，通常由测试失败，代码违例等引起，才能运行。通常在具有黄色指示的Web UI中表示 |
| aborted | 只有当前Pipeline处于“中止”状态时，才会运行，通常是由于Pipeline被手动中止。通常在具有灰色指示的Web UI中表示 |
3）.Parameters-stages
包含一系列一个或多个 stage 指令, stages 部分是流水线描述的大部分"work" 的位置。 建议 stages 至少包含一个 stage 指令用于连续交付过程的每个离散部分,比如构建, 测试, 和部署。
| Required（必需的） | Yes |
|---|---|
| Parameters（参数） | none |
| Allowed（允许） | Only once, inside the pipeline block（在管道内，只有一次） |
4）.Parameters-steps
steps: 包含一个或者多个在stage块中执行的step序列，steps 部分在给定的 stage 指令中执行的定义了一系列的一个或多个steps。
| Required（必需的） | Yes |
|---|---|
| Parameters（参数） | none |
| Allowed（允许） | Inside each stage block（在每个分段块内） |
2、Directives （指令）
1）.environment（环境）
environment指定键值对，可用于step中，主要是为常量或者变量赋值，根据所在的位置来决定其作用范围（类似于java中全局和局部的概念）environment{…}, 大括号里面写一些键值对，也就是定义一些变量并赋值，这些变量就是环境变量。环境变量的作用范围，取决你environment{…}所写的位置，你可以写在顶层环境变量，让所有的stage下的step共享这些变量，也可以单独定义在某一个stage下，只能供这个stage去调用变量，其他的stage不能共享这些变量。一般来说，我们基本上上定义全局环境变量，如果是局部环境变量，我们直接用def关键字声明就可以，没必要放environment{…}里面。
| Required（必需的） | no |
|---|---|
| Parameters（参数） | none |
| Allowed（允许） | Inside the pipeline block, or within stage directives.（在管道内部，或者在阶段指令内部） |
/* groovylint-disable-next-line CompileStatic */
pipeline {
agent {
label '224.86'
}
environment {
unit_test = true
}
stages {
stage('environment') {
steps {
/*steps 引用environment的变量必须使用script包起来*/
script {
/* groovylint-disable-next-line NestedBlockDepth */
if (unit_test == true) {
echo '我完成了environment的开发'
}
}
}
}
}
}
顶层流水线块中使用的 environment 指令将适用于流水线中的所有步骤。
在一个 stage 中定义的 environment 指令只会将给定的环境变量应用于 stage 中的步骤。
environment 块有一个 助手方法 credentials() 定义，该方法可以在 Jenkins 环境中用于通过标识符访问预定义的凭证。
2）.opitions（选择项）
options 指令允许从流水线内部配置特定于流水线的选项。 流水线提供了许多这样的选项, 比如 buildDiscarder,但也可以由插件提供, 比如 timestamps.
| Required（必需的） | NO |
|---|---|
| Parameters（参数） | none |
| Allowed（允许） | Only once, inside the pipeline block（仅有一次，在每个管道块内） |
参数1:buildDiscarder（构建丢弃）
**设置保存最近的记录，为最近的流水线运行的特定数量保存组件和控制台输出。例如: **
options { buildDiscarder(logRotator(numToKeepStr: '1')) }
参数2:disableConcurrentBuilds（禁用并发构建）
不允许同时执行流水线。 可被用来防止同时访问共享资源等。 禁止并行构建，因为用的worksapce还是同一个例如:
options { disableConcurrentBuilds() }
参数3:overrideIndexTriggers（覆盖索引触发器）
允许覆盖分支索引触发器的默认处理。 如果分支索引触发器在多分支或组织标签中禁用,
options { overrideIndexTriggers(true) } //将只允许它们用于促工作。
options { overrideIndexTriggers(false) } //否则,只会禁用改作业的分支索引触发器。
参数4:skipDefaultCheckout（ 跳过默认的代码检出）
在agent 指令中，跳过从源代码控制中检出代码的默认情况。例如:
options { skipDefaultCheckout() }
参数5:skipStagesAfterUnstable（不稳定后跳过该阶段）
一旦构建状态变得UNSTABLE，跳过该阶段。例如:
options { skipStagesAfterUnstable() }
参数6:checkoutToSubdirectory（签出子目录）
在工作空间的子目录中自动地执行源代码控制检出。例如:
options { checkoutToSubdirectory('foo') }
参数7:timeout（设定流水线的超时时间）
设置流水线运行的超时时间, 在此之后，Jenkins将中止流水线。例如:
options { timeout(time: 1, unit: 'HOURS') }
参数8: retry（设定流水线的重试次数）
在失败时, 重新尝试整个流水线的指定次数。
For example: options { retry(3) }
参数9: timestamps（设置日志时间输出）
预谋所有由流水线生成的控制台输出，与该流水线发出的时间一致。 例如:
options { timestamps() }
stage阶段选项：
stage 的 options 指令类似于流水线根目录上的 options 指令。然而， stage -级别 options 只能包括 retry, timeout, 或 timestamps 等步骤, 或与 stage 相关的声明式选项，如 skipDefaultCheckout。
在stage, options 指令中的步骤在进入 agent 之前被调用或在 when 条件出现时进行检查。
可选的阶段选项:
skipDefaultCheckout
//在 agent 指令中跳过默认的从源代码控制中检出代码。例如:
options { skipDefaultCheckout() }
timeout
//设置此阶段的超时时间, 在此之后， Jenkins 会终止该阶段。 例如:
options { timeout(time: 1, unit: 'HOURS') }
retry
//在失败时, 重试此阶段指定次数。 例如:
options { retry(3) }
timestamps
//预谋此阶段生成的所有控制台输出以及该行发出的时间一致。例如:
options { timestamps() }
pipeline {
agent {
label '224.86'
}
environment {
VERSION = '1.1.1'
ENV_TYPE = 'DEV'
}
options {
buildDiscarder(logRotator(numToKeepStr: '1'))//丢弃旧的构建
disableConcurrentBuilds()//禁止并行构建
skipDefaultCheckout()//跳过默认的代码检出
timeout(time: 1, unit: 'HOURS')//设定流水线的超时时间
retry(1)//设定流水线的重试次数为1次
timestamps()//设置日志输出时间
}
stages {
stage('Hello Opitions') {
environment {
VERSION = '1.0.0'
}
steps {
script {
echo "The variable version is ${VERSION}"
echo "The variable env_type is ${env.ENV_TYPE}"
echo "The job name is ${env.JOB_NAME}" //内置的环境变量
env.JOB_NAMEA = 'mytest-pipeline' //自定义的全局变量,也就是整个流水线可以去使用
echo "the variable is ${env.JOB_NAMEA}"
}
}
}
}
}
3）.parameters（参数化构建）
parameters 指令提供了一个用户在触发流水线时应该提供的参数列表。
| Required（必需的） | NO |
|---|---|
| Parameters（参数） | none |
| Allowed（允许） | Only once, inside the pipeline block（仅有一次，在每个管道块内） |
- 定义： 流水线在运行时设置的参数，UI页面的参数。所有的参数都存储在params对象中。
- 将web ui页面中定义的参数，以代码的方式定义。
parameters {
string defaultValue: '1.1.1', description: '版本号', name: 'Version', trim: true
}
参数1.string
字符串类型的参数, 例如:
parameters { string(name: 'DEPLOY_ENV', defaultValue: 'staging', description: '') }
参数2.booleanParam
布尔参数, 例如:
parameters { booleanParam(name: 'DEBUG_BUILD', defaultValue: true, description: '') }
4）.triggers（触发器）
| Required（必需的） | NO |
|---|---|
| Parameters（参数） | none |
| Allowed（允许） | Only once, inside the pipeline block（仅有一次，在每个管道块内） |
该triggers指令定义了Pipeline应重新触发的自动化方式。对于与源代码集成的Pipeline，如GitHub或BitBucket，triggers可能不需要基于webhook的集成可能已经存在。目前有三个可用的触发器是cron和pollSCM 和 upstream。
这块是设置什么条件下触发pipeline代码执行，以及触发的频率,用来控制轮询频率的，特别适合周期的自动化提交。
参数1.cron（计划任务）
接收 cron 样式的字符串来定义要重新触发流水线的常规间隔 ,比如:
triggers { cron('H */4 * * 1-5') }
参数2.pollSCM（查询源代码库）
接收 cron 样式的字符串来定义一个固定的间隔，在这个间隔中，Jenkins 会检查新的源代码更新。如果存在更改, 流水线就会被重新触发。例如:
triggers { pollSCM('H */4 * * 1-5') }
参数3.upstream（上游）
接受逗号分隔的工作字符串和阈值。 当字符串中的任何作业以最小阈值结束时，流水线被重新触发。例如:
triggers { upstream(upstreamProjects: 'job1,job2', threshold:hudson.model.Result.SUCCESS) }
【参数解释说明】
| MINUTE: | Minutes with in the hour(0-59)每小时的分钟(0-59)分钟 |
|---|---|
| HOUR: | The hour of the day(0-23) 每天（0-23）小时 |
| DOM: | The day of the month(1-31) 每月（1-31）天 |
| MONTH: | The month of the year (1-12)每年（1-12）月 |
| DOW: | The day of the week(1-7)每周（1-7）天 |
H H(9-16)/2 * * 1-5) 的含义就是：
第一部分“H” 表示hash，记住不是表示hour，是一个散列值，含义就是在一个小时之内，会执行一次，但是这次是一个散列值，而且不会并发执行。
第二部分“H(9-16)/2”，表示白天在早上9点到下午5点，每间隔2小时执行一次。
第三部分“*“，每天执行
第四部分“*“表示每月执行
第五部分“1-5“ 表示周一到周五执行
所以上面这个表达式“H H(9-16)/2 * * 1-5) “的含义就是，在每个月的周一到周五的白天，从早上9点到下午5点，每间隔两个小时去触发一次自动化构建。
5）.stage （阶段）
stage 指令在 stages 部分进行，应该包含一个 实际上, 流水线所做的所有实际工作都将封装进一个或多个 stage 指令中。
| Required | At least one（至少一个） |
|---|---|
| Parameters | One mandatory parameter, a string for the name of the stage.（一个必选参数，阶段名称的字符串） |
| Allowed（允许） | Inside the stages section（在阶段内） |
stage（阶段）特点：
- stage一定是在stages{…}里面;
- 一个pipeline{…}中至少有一个stages{…}和一个stage{…};
- 一个stage{…}中至少有一个steps{…};
- Stage{…}还有一个特点就是，里面有一个强制的字符串参数，这个字符串参数就是描述这个stage是干嘛的，这个字符串参数是不支持变量的，只能你自己取名一个描述字段。
6）.tool（工具）
标签：pipeline,Pipeline,笔记,参数,agent,流水线,jenkins,stage 来源： https://www.cnblogs.com/cndevops/p/15055908.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。