jenkins-pipline

1、流水线介绍

Jenkins 流水线 (或简单的带有大写"P"的"Pipeline") 是一套插件，它支持实现和集成 continuous delivery pipelines 到Jenkins。
_continuous delivery (CD)pipeline_是你的进程的自动表达，用于从版本控制向用户和客户获取软件。 你的软件的每次的变更(在源代码控制中提交)在它被释放的路上都经历了一个复杂的过程 on its way to being released. 这个过程包括以一种可靠并可重复的方式构建软件, 以及通过多个测试和部署阶段来开发构建好的软件 (c成为 "build") 。
流水线提供了一组可扩展的工具，通过 Pipeline domain-specific language (DSL) syntax. [1]对从简单到复杂的交付流水线 "作为代码" 进行建模。
对Jenkins 流水线的定义被写在一个文本文件中 (成为 Jenkinsfile)，该文件可以被提交到项目的源代码的控制仓库。 [2] 这是"流水线即代码"的基础; 将CD 流水线作为应用程序的一部分，像其他代码一样进行版本化和审查。 创建 Jenkinsfile并提交它到源代码控制中提供了一些即时的好处:

• 自动地为所有分支创建流水线构建过程并拉取请求。
• 在流水线上代码复查/迭代 (以及剩余的源代码)。
• 对流水线进行审计跟踪。
• 该流水线的真正的源代码 [3], 可以被项目的多个成员查看和编辑。
  While定义流水线的语法, 无论是在 web UI 还是在 Jenkinsfile 中都是相同的, 通常认为在Jenkinsfile 中定义并检查源代码控制是最佳实践。

2、声明式和脚本化的流水线语法

Jenkinsfile 能使用两种语法进行编写 - 声明式和脚本化。
声明式和脚本化的流水线从根本上是不同的。 声明式流水线的是 Jenkins 流水线更近的特性:

• 相比脚本化的流水线语法，它提供更丰富的语法特性,
• 是为了使编写和读取流水线代码更容易而设计的。
  然而，写到Jenkinsfile中的许多单独的语法组件(或者 "步骤"), 通常都是声明式和脚本化相结合的流水线。 在下面的 [pipeline-concepts] 和 [pipeline-syntax-overview] 了解更多这两种语法的不同。

3、Why Pipeline?

本质上，Jenkins 是一个自动化引擎，它支持许多自动模式。 流水线向Jenkins中添加了一组强大的工具, 支持用例 简单的持续集成到全面的CD流水线。通过对一系列的相关任务进行建模, 用户可以利用流水线的很多特性:

• Code: 流水线是在代码中实现的，通常会检查到源代码控制, 使团队有编辑, 审查和迭代他们的交付流水线的能力。
• Durable: 流水线可以从Jenkins的主分支的计划内和计划外的重启中存活下来。
• Pausable: 流水线可以有选择的停止或等待人工输入或批准，然后才能继续运行流水线。
• Versatile: 流水线支持复杂的现实世界的 CD 需求, 包括fork/join, 循环, 并行执行工作的能力。
• Extensible:流水线插件支持扩展到它的DSL [1]的惯例和与其他插件集成的多个选项。
  然而， Jenkins一直允许以将自由式工作链接到一起的初级形式来执行顺序任务, [4] 流水线使这个概念成为了Jenkins的头等公民。
  构建一个的可扩展的核心Jenkins值, 流水线也可以通过 Pipeline Shared Libraries 的用户和插件开发人员来扩展。

4、流水线代码介绍

4.1、agent指定流水线的执行节点

参数：
- any:
   **在任何节点上执行pipline**
- node:
   在没有指定agent的时候默认执行**
- label：
   在指定的表签节点上运行pipline

4.2、post

定义一个或者多个steps，这些阶段根据流水线的完成情况而运行（取决于流水线post部分位置）
指定构建后操作
always{ } ：总是执行脚本片段
success{ } : 成功后执行
failure{ } ：失败后执行
aborted{ } : 取消后执行
currendBuild 是一个全局变量
description: 构建描述

4.3、agent(代理)

agent制定流水线的执行节点
参数：
any : 在任何节点上执行pipline
none : 没有指定agent的时候默认
label : 在指定节点上运行pipline
node： 允许格外的选项
agent {
	node{
			//指定运行节点的表签或者名称
			label "master"
		//指定运行的工作目录（可选）
			customWorkspace "${workspace}"
		}
}

4.4、post的语法使用

定义一个或者多个steps，这些阶段根据流水线或者阶段的完成情况而运行（取决流水线的post的部分位置）。post支持以下的post-condition块其中之一：
always ： 无论完成流水线或者阶段的完成的状态
changed : 只有当流水线或者阶段完成状态与之前的不同时
failure ： 只有当流水线或者阶段状态为“failure”运行
success :只有当流水线或者阶段状态为“success”运行
unstable: 只有当流水线或者阶段状态为“unstable”运行，例如：测试失败
aborted : 只有当流水线或者阶段状态为“aborted”运行，例如：手动取消

4.5、stages（阶段）

包含一系列一个或者多个的stage的指令，建议stages至少包含一个stage指令用于连续交付过程的每一个离散部分，比如：构建、测试和部署
pipeline {	
​	agent any
​		stages {
​				stage('checkout') { 
​					steps {
				}
​		}			
	}
}

4.6、environment环境变量

environment指令指定一系列键值对，这些键值对将被定义为所有step或特定stage的step的环境变量，具体取决于environment指令位于Pipeline中的位置。
该指令支持一种特殊的助手方法credentials()，可以通过Jenkins环境中的标识符来访问预定义的凭据。对于类型为“Secret Text”的凭据，该 credentials()方法将确保环境变量中包含该Secret Text内容。对于“标准用户名和密码”类型的凭证，指定的环境变量将被设置为username:password并且将自动定义两个附加的环境变量：MYVARNAME_USR和MYVARNAME_PSW。

是否必填	否
参数	没有
允许出现在	在pipeline块内或stage内
示例

Jenkinsfile (Declarative Pipeline)
pipeline {
​    agent any
​    environment { 
​        CC = 'clang'
​    }
​    stages {
​        stage('Example') {
​            environment { 
​                AN_ACCESS_KEY = credentials('my-prefined-secret-text') 
​            }
​            steps {
​                sh 'printenv'
​            }
​        }
​    }
}
顶层流水线块中使用的 environment 指令将适用于流水线中的所有步骤。
在一个 stage 中定义的 environment 指令只会将给定的环境变量应用于 stage 中的步骤。
environment 块有一个 助手方法 credentials() 定义，该方法可以在 Jenkins 环境中用于通过标识符访问预定义的凭证。

4.7、options

options 指令允许从流水线内部配置特定于流水线的选项。 流水线提供了许多这样的选项, 比如 buildDiscarder,但也可以由插件提供, 比如 timestamps.

Required	No
Parameters	None
Allowed	Only once, inside the pipeline block.

可用选项
buildDiscarder
为最近的流水线运行的特定数量保存组件和控制台输出。例如: 
options { buildDiscarder(logRotator(numToKeepStr: '1')) }
disableConcurrentBuilds
不允许同时执行流水线。 可被用来防止同时访问共享资源等。 例如: 
options { disableConcurrentBuilds() }
overrideIndexTriggers
允许覆盖分支索引触发器的默认处理。 如果分支索引触发器在多分支或组织标签中禁用, 		   
options { overrideIndexTriggers(true) } 将只允许它们用于促工作。否则, 
options { overrideIndexTriggers(false) } 只会禁用改作业的分支索引触发器。
skipDefaultCheckout
在`agent` 指令中，跳过从源代码控制中检出代码的默认情况。例如: options { skipDefaultCheckout() }
skipStagesAfterUnstable
一旦构建状态变得UNSTABLE，跳过该阶段。例如: options { skipStagesAfterUnstable() }
checkoutToSubdirectory
在工作空间的子目录中自动地执行源代码控制检出。例如: options { checkoutToSubdirectory('foo') }
timeout
设置流水线运行的超时时间, 在此之后，Jenkins将中止流水线。例如: options { timeout(time: 1, unit: 'HOURS') }
retry
在失败时, 重新尝试整个流水线的指定次数。 For example: options { retry(3) }
timestamps
预谋所有由流水线生成的控制台输出，与该流水线发出的时间一致。 例如: options { timestamps() }
Example
Jenkinsfile (Declarative Pipeline)
pipeline {
​    agent any
​    options {
​        timeout(time: 1, unit: 'HOURS') 
​    }
​    stages {
​        stage('Example') {
​            steps {
​                echo 'Hello World'
​            }
​        }
​    }
}
指定一个小时的全局执行超时, 在此之后，Jenkins 将中止流水线运行

4.8、参数
parameters 指令提供了一个用户在触发流水线时应该提供的参数列表。这些用户指定参数的值可通过 params 对象提供给流水线步骤, 了解更多请参考示例。

Required	No
Parameters	None
Allowed	Only once, inside the pipeline block.

可用参数
string
字符串类型的参数, 例如: parameters { string(name: 'DEPLOY_ENV', defaultValue: 'staging', description: '') }
booleanParam
布尔参数, 例如: parameters { booleanParam(name: 'DEBUG_BUILD', defaultValue: true, description: '') }
示例
Jenkinsfile (Declarative Pipeline)
pipeline {
​    agent any
​    parameters {
​        string(name: 'PERSON', defaultValue: 'Mr Jenkins', description: 'Who should I say hello to?')
​    }
​    stages {
​        stage('Example') {
​            steps {
​                echo "Hello ${params.PERSON}"
​            }
​        }
​    }
}

4.9、触发器

triggers 指令定义了流水线被重新触发的自动化方法。对于集成了源（ 比如 GitHub 或 BitBucket）的流水线, 可能不需要 triggers ，因为基于 web 的集成很肯能已经存在。 当前可用的触发器是 cron, pollSCM 和 upstream。

Required	No
Parameters	None
Allowed	Only once, inside the pipeline block.

cron
接收 cron 样式的字符串来定义要重新触发流水线的常规间隔 ,比如: |
triggers { cron('H \*/4 \* \* 1-5') }
pollSCM
接收 cron 样式的字符串来定义一个固定的间隔，在这个间隔中，Jenkins 会检查新的源代码更新。如果存在更改, 流水线就会被重新触发。例如: 
triggers { pollSCM('H \*/4 \* \* 1-5') }
upstream
接受逗号分隔的工作字符串和阈值。 当字符串中的任何作业以最小阈值结束时，流水线被重新触发。	例如: 
triggers { upstream(upstreamProjects: 'job1,job2', threshold: hudson.model.Result.SUCCESS) }
pollSCM 只在Jenkins 2.22 及以上版本中可用。
示例
Jenkinsfile (Declarative Pipeline)
pipeline {
​    agent any
​    triggers {
​        cron('H \*/4 \* \* 1-5')
​    }
​    stages {
​        stage('Example') {
​            steps {
​                echo 'Hello World'
​            }
​        }
​    }
}

4.10、工具tools

定义自动安装和放置 PATH 的工具的一部分。如果 agent none 指定，则忽略该操作。
支持工具
maven
jdk
gradle
示例
Jenkinsfile (Declarative Pipeline)
pipeline {
​    agent any
​    tools {
​        maven 'apache-maven-3.0.1' 
​    }
​    stages {
​        stage('Example') {
​            steps {
​                sh 'mvn --version'
​            }
​        }
​    }
}

4.11、input****

stage 的 input 指令允许你使用 input step提示输入。 在应用了 options 后，进入 stage 的 agent 或评估 when 条件前， stage 将暂停。 如果 input 被批准, stage 将会继续。 作为 input 提交的一部分的任何参数都将在环境中用于其他 stage。
配置项
message
必需的。 这将在用户提交 input 时呈现给用户。
id
input 的可选标识符， 默认为 stage 名称。
ok
`input`表单上的"ok" 按钮的可选文本。
submitter
可选的以逗号分隔的用户列表或允许提交 input 的外部组名。默认允许任何用户。
submitterParameter
环境变量的可选名称。如果存在，用 submitter 名称设置。
parameters
提示提交者提供的一个可选的参数列表。 更多信息参见 [parameters]。
示例
Jenkinsfile (Declarative Pipeline)
pipeline {
​    agent any
​    stages {
​        stage('Example') {
​            input {
​                message "Should we continue?"
​                ok "Yes, we should."
​                submitter "alice,bob"
​                parameters {
​                    string(name: 'PERSON', defaultValue: 'Mr Jenkins', description: 'Who should I say hello to?')
​                }
​            }
​            steps {
​                echo "Hello, ${PERSON}, nice to meet you."
​            }
​        }
​    }
}

4.12、条件判断when

when
when 指令允许流水线根据给定的条件决定是否应该执行阶段。 when 指令必须包含至少一个条件。 如果 when 指令包含多个条件, 所有的子条件必须返回True，阶段才能执行。 这与子条件在 allOf 条件下嵌套的情况相同 (参见下面的示例)。
使用诸如 not, allOf, 或 anyOf 的嵌套条件可以构建更复杂的条件结构 can be built 嵌套条件刻意潜逃到任意深度。

Required	No
Parameters	None
Allowed	Inside a stage directive

内置条件
branch
当正在构建的分支与模式给定的分支匹配时，执行这个阶段, 例如: when { branch 'master' }。注意，这只适用于多分支流水线。
environment
当指定的环境变量是给定的值时，执行这个步骤, 例如: when { environment name: 'DEPLOY_TO', value: 'production' }
expression
当指定的Groovy表达式评估为true时，执行这个阶段, 例如: when { expression { return params.DEBUG_BUILD } }
not
当嵌套条件是错误时，执行这个阶段,必须包含一个条件，例如: when { not { branch 'master' } }
allOf
当所有的嵌套条件都正确时，执行这个阶段,必须包含至少一个条件，例如: when { allOf { branch 'master'; environment name: 'DEPLOY_TO', value: 'production' } }
anyOf
当至少有一个嵌套条件为真时，执行这个阶段,必须包含至少一个条件，例如: when { anyOf { branch 'master'; branch 'staging' } }
在进入 stage 的 agent 前评估 when
默认情况下, 如果定义了某个阶段的代理，在进入该`stage` 的 agent 后该 stage 的 when 条件将会被评估。但是, 可以通过在 when 块中指定 beforeAgent 选项来更改此选项。 如果 beforeAgent 被设置为 true, 那么就会首先对 when 条件进行评估 , 并且只有在 when 条件验证为真时才会进入 agent 。