Jenkins中插件 pipeline 中声明式流水线的语法
- 声明式流水线
- 脚本化流水线
声明式流水线
pipeline {
agent any
stages {
stage('Example') {
steps {
echo 'Hello World'
}
}
}
}
脚本化流水线
node {
stage('Example') {
if (env.BRANCH_NAME == 'master') {
echo 'I only execute on the master branch'
} else {
echo 'I execute elsewhere'
}
}
}
node('slave001') { 最外层必须是node节点，这里单独制定运行的jenkins节点，通常不用指定，由jenkins master分配任务即可。这种写法属于Scripted Pipeline。
stage('Prepare') {} stage是一个阶段的语法，括号里阶段名称。脚本从node开始，按顺序向下执行。遇到的第一个stage就是第一个阶段。
使用echo xxxx来输出文字，给出进度信息。
checkout scm 是Jenkins固定获取代码的方法，会输出Check out from version control。
pom = readMavenPom file: 'location/pom.xml' 是读取workspace下相对目录的pom文件。这个需要Jenkins 安装Pipeline Utility Steps插件。通过${pom.groupId}-${pom.artifactId}来获取pom信息. 我的pom在子module location里。
docker_host = "docker.ryan-miao.com" 声明一个全局的变量，如果只想在方法体 {}中使用，可以加def。
${docker_host} 变量可以通过这样类似shell的方式获取。
build_tag = sh(returnStdout: true, script: 'git rev-parse --short HEAD').trim() 用来获取git的commit id
Build阶段执行docker命令打包，把我们的变量传递到Dockerfile. 我的Dockerfile同样在子module location下。
withCredentials可以调用存储在Jenkins里的凭证。这个需要安装Credentials Binding Plugin.
input会产生一个交互式的按钮，需要手动点击通过才会继续，否则暂停。这个只是暂停下一步，线程还在运行。所以，需要单独提出node之外，再添加一个超时设置。参见“input” step blocks executor
stash暂存文件，参见官方文档. 主要用来把这次build过程中的某个文件给暂存，只在本次build有效。本次不需要。
timeout 主要用来设置超时，参见官方文档, 时间单位有： NANOSECONDS, MICROSECONDS, MILLISECONDS, SECONDS, MINUTES, HOURS, DAYS。这里等待用户确认是否继续，若超过10分钟还没有确认，则停止。
声明性Pipeline
声明性Pipeline是Jenkins Pipeline 的一个相对较新的补充， 它在Pipeline子系统之上提出了一种更为简化和有意义的语法。
所有有效的声明性Pipeline必须包含在一个pipeline块内，例如：
pipeline {
/* insert Declarative Pipeline here */
}
声明性Pipeline中有效的基本语句和表达式遵循与Groovy语法相同的规则 ，但有以下例外：
- Pipeline的顶层必须是块，具体来说是：pipeline { }
- 没有分号作为语句分隔符。每个声明必须在自己的一行
- 块只能包含章节， 指令，步骤或赋值语句。
- 属性引用语句被视为无参数方法调用。所以例如，输入被视为input()
您可以使用 声明性指令生成器 来帮助您配置声明性Pipeline中的指令和部分。
Sections
声明性Pipeline中的Sections通常包含一个或多个指令或步骤。
代理 agent
agent指定整个Pipeline或特定stage将在Jenkins环境中执行的位置，具体取决于该agent 部分的位置。该部分必须在pipeline块内的顶层定义，stage块内的agent是可选的 。
| 是否必填 | 是 |
| 参数 | 如下面所描述的 |
| 允许出现在 | 在顶级pipeline块和每个stage块中。 |
参数
为了支持Pipeline作者可能拥有的各种使用场景，agent部分支持几种不同类型的参数。这些参数可以应用于pipeline块的顶层，也可以应用在每个stage指令内。
- any - 在任何可用的代理上执行Pipeline或stage。例如：agent any
- none - 当在pipeline块的顶层应用时，将不会为整个Pipeline运行分配全局代理，并且每个stage部分将需要包含其自己的agent部分。例如：agent none
- label - 使用提供的标签在Jenkins环境中可用的代理上执行Pipeline或stage性执行。例如：agent { label 'my-defined-label' }
- node - agent { node { label 'labelName' } }行为和 agent { label 'labelName' }相同，但node允许其他选项（如customWorkspace）。
- docker - 用给定的容器执行Pipeline，或stage，将被动态地提供一个预先配置成基于Docker-based Pipelines的节点，或和label参数匹配的任选节点。 docker还可以接受一个args参数，可以直接将参数传递给docker run命令。例如：agent { docker 'maven:3-alpine' }或
agent {
docker {
image 'maven:3-alpine'
label 'my-defined-label'
args '-v /tmp:/tmp'
}
}
-
dockerfile -使用从Dockerfile源存储库中包含的容器构建容器来执行Pipeline或stage 。为了使用此选项，Jenkinsfile必须从Multibranch Pipeline或Pipeline from SCM加载。通常Dockerfile在源码库的根路径：agent { dockerfile true }。如果Dockerfile在其他目录中建立，请使用以下dir选项：agent { dockerfile { dir 'someSubDir' } }。您可以使用additionalBuildArgs选项将其他参数传递给docker build ...命令，如agent { dockerfile { additionalBuildArgs '--build-arg foo=bar' } }。
常用选项
下面是可以用于两个或多个agent的常用选项。在没有明确说明的情况下选项是可选的。
label - 一个字符串。在这些标签上运行Pipeline或每个stage。此选项可用于node，docker和dockerfile，并且 对于node是必需的。
customWorkspace - 一个字符串。运行Pipeline或每个stage， 在这个agent的自定义的工作空间内，而不是默认的。它可以是相对路径，在这种情况下，自定义工作区将位于节点上的工作空间根目录下，也可以是绝对路径。例如：
agent {
node {
label 'my-defined-label'
customWorkspace '/some/other/path'
}
}
reuseNode - 一个布尔值，默认为false。如果为true，则在同一工作空间中，而不是完全在新节点上运行Pipeline顶层指定的节点上的容器。此选项适用于docker和dockerfile，并且仅在agent的每个stage内才有效果。
Jenkinsfile (Declarative Pipeline)
pipeline {
agent { docker 'maven:3-alpine' }
stages {
stage('Example Build') {
steps {
sh 'mvn -B clean verify'
}
}
}
}
发布 post
post定义将在Pipeline运行或stage结束时运行的操作。一些条件后的块的内支持post： always，changed，failure，success，unstable，和aborted。这些块允许在Pipeline运行或stage结束时执行步骤，具体取决于Pipeline的状态。
| 是否必填 | 否 |
| 参数 | 没有 |
| 允许出现在 | 在顶级pipeline块和每个stage块中。 |
条件
Always - 无论Pipeline运行的完成状态如何都会运行。
changed - 只有当前Pipeline运行的状态与先前完成的Pipeline的状态不同时，才能运行。
Failure - 仅当当前Pipeline处于“失败”状态时才运行，通常在Web UI中用红色指示表示。
success - 仅当当前Pipeline具有“成功”状态时才运行，通常在具有蓝色或绿色指示的Web UI中表示。
Unstable - 只有当前Pipeline具有“不稳定”状态，通常由测试失败，代码违例等引起，才能运行。通常在具有黄色指示的Web UI中表示。
Aborted - 只有当前Pipeline处于“中止”状态时，才会运行，通常是由于Pipeline被手动中止。通常在具有灰色指示的Web UI中表示。
Cleanup - 无论管道或stage的状态如何，在跑完所有其他的post条件后运行此条件下 的post步骤。
Jenkinsfile (Declarative Pipeline)
pipeline {
agent any
stages {
stage('Example') {
steps {
echo 'Hello World'
}
}
}
post {
always {
echo 'I will always say Hello again!'
}
}
}
-
通常，该post部分应放在Pipeline末端
-
post条件块包含的步骤和steps中的步骤用法相同
stage stages
包含一个或多个stage指令的序列，该stages部分是Pipeline 描述的大部分“工作”所在的位置。建议stages至少为持续交付流程的每个独立部分包含至少一个stage指令，例如构建，测试和部署。
| 是否必填 | 是 |
| 参数 | 没有 |
| 允许出现在 | 在pipeline内只有一次。 |
stages部分一般跟在agent， options等后面。
pipeline {
agent any
stages {
stage('Example') {
steps {
echo 'Hello World'
}
}
}
}
步骤 steps
steps部分定义了在给定stage指令中执行的一系列一个或多个步骤。
|
是否必填
|
是
|
|
参数
|
没有
|
|
允许出现在
|
每个stage块内
|
例如
Jenkinsfile (Declarative Pipeline)
pipeline {
agent any
stages {
stage('Example') {
steps {
echo 'Hello World'
}
}
}
}
指令 Directives
环境 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顶级pipeline块中使用的指令将适用于Pipeline中的所有步骤
- 在一个stage中定义的environment指令只将给定的环境变量应用于该stage中的步骤
- environment具有一个帮助方法credentials()，可用于在Jenkins环境中通过其标识符访问预定义的凭据
选项 options
options指令允许在Pipeline内配置Pipeline专用选项。Pipeline提供了许多这些选项，例如buildDiscarder，但它们也可能由插件提供，例如 timestamps。
| 是否必填 | 否 |
| 参数 | 没有 |
| 允许出现在 | 在pipeline块内，只有一次 |
可用选项
-
buildDiscarder持久化工件和控制台输出，用于保存Pipeline最近几次运行的数据。例如：options { buildDiscarder(logRotator(numToKeepStr: '1')) }
-
checkoutToSubdirectory在工作区的子目录中执行源代码检出。例如：options { checkoutToSubdirectory('foo') }
-
disableConcurrentBuilds不允许并行执行Pipeline。可用于防止同时访问共享资源等。例如：options { disableConcurrentBuilds() }
-
preserveStashes保留已完成构建的存储，用于stage重新启动。例如：options { preserveStashes() }保存最近完成的构建中的stash，或者options { preserveStashes(5) }保留最近五个完成的构建中的stash。
-
quietPeriod设置管道的静默期（以秒为单位），覆盖全局默认值。例如：options { quietPeriod(30) }
-
retry如果失败，请按指定的次数重试整个管道。例如：options { retry(3) }
-
skipDefaultCheckout在agent指令中默认跳过源代码检出。例如：options { skipDefaultCheckout() }
-
skipStagesAfterUnstable一旦构建状态进入了“不稳定”状态，就跳过stage。例如：options { skipStagesAfterUnstable() }
-
timeout设置Pipeline运行的超时时间，之后Jenkins应该中止Pipeline。例如：options { timeout(time: 1, unit: 'HOURS') }
-
timestamps当执行时，预处理由Pipeline生成的所有控制台输出运行时间。例如：options { timestamps() }
例如： 指定一个小时的全局执行超时，之后Jenkins将中止Pipeline运行
Jenkinsfile (Declarative Pipeline)
pipeline {
agent any
options {
timeout(time: 1, unit: 'HOURS')
}
stages {
stage('Example') {
steps {
echo 'Hello World'
}
}
}
}
stage选项
stage的options指令类似于Pipeline根目录中的options指令。但是，stage的 options只能包含与stage相关的步骤，如retry，timeout或timestamps，或声明性选项，如skipDefaultCheckout。
在stage内，options在进入agent或检查任何when条件之前调用指令中的步骤。
可用的stage选项
-
skipDefaultCheckout默认情况下，在agent指令中跳过检查源代码管理中的代码。例如：options { skipDefaultCheckout() }
-
timeout设置此stage的超时时间，之后Jenkins应该中止该stage。例如：options { timeout(time: 1, unit: 'HOURS') }
-
retry如果失败，请重试此stage指定次数。例如：options { retry(3) }
-
timestamps当执行时，预处理由Pipeline生成的所有控制台输出运行时间。例如：options { timestamps() }
-
例如：为stageExample指定一小时的执行超时，之后Jenkins将中止Pipeline运行。
pipeline {
agent any
stages {
stage('Example') {
options {
timeout(time: 1, unit: 'HOURS')
}
steps {
echo 'Hello World'
}
}
}
}
参数 parameters
parameters指令提供用户在触发Pipeline时应提供的参数列表。这些用户指定的参数的值通过该params对象可用于Pipeline步骤，具体用法见示例。
| 是否必填 | 否 |
| 参数 | 没有 |
| 允许出现在 | 在pipeline块内，只有一次 |
可用参数
-
string字符串类型的参数，例如： parameters { string(name: 'DEPLOY_ENV', defaultValue: 'staging', description: '') }
-
文本一个text参数，可以包含多行，例如： parameters { text(name: 'DEPLOY_TEXT', defaultValue: 'One\nTwo\nThree\n', description: '') }
-
booleanParam一个布尔参数，例如： parameters { booleanParam(name: 'DEBUG_BUILD', defaultValue: true, description: '') }
-
choice选择参数，例如： parameters { choice(name: 'CHOICES', choices: ['one', 'two', 'three'], description: '') }
-
file一个文件参数，指定用户在计划构建时要提交的文件，例如： parameters { file(name: 'FILE', description: 'Some file to upload') }
-
password密码参数，例如： parameters { password(name: 'PASSWORD', defaultValue: 'SECRET', description: 'A secret password') }
Jenkinsfile (Declarative Pipeline)
pipeline {
agent any
parameters {
string(name: 'PERSON', defaultValue: 'Mr Jenkins', description: 'Who should I say hello to?')
text(name: 'BIOGRAPHY', defaultValue: '', description: 'Enter some information about the person')
booleanParam(name: 'TOGGLE', defaultValue: true, description: 'Toggle this value')
choice(name: 'CHOICE', choices: ['One', 'Two', 'Three'], description: 'Pick something')
password(name: 'PASSWORD', defaultValue: 'SECRET', description: 'Enter a password')
file(name: "FILE", description: "Choose a file to upload")
}
stages {
stage('Example') {
steps {
echo "Hello ${params.PERSON}"
echo "Biography: ${params.BIOGRAPHY}"
echo "Toggle: ${params.TOGGLE}"
echo "Choice: ${params.CHOICE}"
echo "Password: ${params.PASSWORD}"
}
}
}
}
触发器 triggers
triggers指令定义了Pipeline应重新触发的自动化方式。对于与源代码集成的Pipeline，如GitHub或BitBucket，triggers可能不需要基于webhook的集成可能已经存在。目前只有两个可用的触发器是cron和pollSCM。
|
需要
|
没有
|
|
参数
|
没有
|
|
允许
|
只有一次，在pipeline块内。
|
-
cron接受一个cron风格的字符串来定义Pipeline应重新触发的常规间隔，例如： triggers { cron('H 4/* 0 0 1-5') }
-
pollSCM接受一个cron风格的字符串来定义Jenkins应该检查新的源更改的常规间隔。如果存在新的更改，则Pipeline将被重新触发。例如：triggers { pollSCM('H 4/* 0 0 1-5') }
该pollSCM触发器仅在Jenkins 2.22或更高版本可用
Jenkinsfile (Declarative Pipeline)
pipeline {
agent any
triggers {
cron('H 4/* 0 0 1-5')
}
stages {
stage('Example') {
steps {
echo 'Hello World'
}
}
}
}
Jenkins cron 语法
Jenkins cron语法遵循cron实用程序的语法 （略有不同）。具体来说，每行包含由TAB或空格分隔的5个字段：
| 分钟 | 小时 | DOM | 月 | DOW |
| 一小时内的分钟数（0-59） | 一天中的小时（0-23） | 每月的某一天（1-31） | 月（1-12） | 星期几（0-7），其中0和7是星期日。 |
要为一个字段指定多个值，可以使用以下运算符。按优先顺序排列，
- * 指定所有有效值
- M-N 指定一系列值
- M-N/X或者按照指定范围或整个有效范围的*/X间隔步长X
- A,B,…,Z 枚举多个值
为了允许定期计划的任务在系统上产生均匀负载，应尽可能使用符号H（“哈希”）。例如，使用0 0 * * *十几个日常工作将导致午夜大量飙升。相比之下，使用H H * * *仍然会每天执行一次，但不能同时执行，更好地使用有限的资源。
所述H符号可以与范围内使用。例如，H H(0-7) * * * 表示从凌晨12:00（午夜）到早上7:59之间的某个时间段。您也可以使用H带有或不带范围的步长间隔。
H符号可以被认为是在一定范围内的随机值，但它实际上是作业名称的hash值，而不是随机函数的哈希值，所以对于给定的项目该值仍然是稳定的。
请注意，对于月份日期字段，由于月份长度可变，短期周期（例如/3或 H/3）将不会在大多数月份结束时始终如一地工作）。例如，/3 将在第1st, 4th, …31st 天运行, 然后在下个月的第一天运行。 哈希总是在1-28的范围内运行, 所以 H/3在一个月末将产生3到6天的空隙。（更长的周期也会有不一致的长度，但效果可能相对不太明显。）
以#开头的行和空行将被当做注释忽略。
此外，还有如下方便的别名：@yearly，@annually，@monthly， @weekly，@daily，@midnight，和@hourly。这些使用哈希系统进行自动平衡。例如，@hourly和H * * * *都意味着在一小时内的任何时间。 @midnight实际上意味着在凌晨12:00到凌晨2:59之间的某个时间。
每十五分钟（也许在：07，：22，：37，：52）
triggers{ cron('H/15 * * * *') }
每小时上半场每十分钟一次（三次，也许在：04，：14，：24）
triggers{ H(0-29)/10 * * * *) }
从上午9:45开始每小时45分钟一次，每个工作日下午3:45结束。
triggers{ 45 9-16/2 * * 1-5) }
每个工作日上午9点到下午5点之间每两小时一次（可能在上午10:38，下午12点38分，下午2点38分，下午4点38分）
triggers{ H H(9-16)/2 * * 1-5) }
除了12月之外，每个月的1日和15日每天一次
triggers{ H H 1,15 1-11 *) }
阶段 stage
stage指令在stages部分中，应包含步骤部分，可选agent部分或其他特定于stage的指令。实际上，Pipeline完成的所有实际工作都将包含在一个或多个stage指令中。
| 是否必填 | 至少一个 |
| 参数 | 一个必填参数，一个用于stage名称的字符串 |
| 允许出现在 | 在stages内 |
例如：Jenkinsfile (Declarative Pipeline)
pipeline {
agent any
stages {
stage('Example') {
steps {
echo 'Hello World'
}
}
}
}
工具 tools
定义自动安装和放置工具的部分PATH。如果指定agent none，这将被忽略。
|
是否必填
|
否
|
|
参数
|
没有
|
|
允许出现在
|
在pipeline块或stage块内
|
支持的工具
- maven
- jdk
- gradle
例如： 工具名称必须在Jenkins 管理Jenkins → 全局工具配置中预置。
Jenkinsfile (Declarative Pipeline)
pipeline {
agent any
tools {
maven 'apache-maven-3.0.1'
}
stages {
stage('Example') {
steps {
sh 'mvn --version'
}
}
}
}
输入 input
stage的input指令允许您使用input步骤提示输入 。在进入stage的agent或评估其when状态之前，stage将处于暂停状态。如果input 获得批准，stage则将继续。作为input提供的任何参数将在stage的剩下部分的环境中可用 。
配置选项
-
message必填。这将在用户提交input时呈现给用户。
-
id这是一个可选的标识符input。默认为stage名称。
-
okinput表单上“ok”按钮的可选文本。
-
submitter允许提交此input选项的用户或外部组名列表，用逗号分隔。默认允许任何用户。
-
submitterParameter要使用submitter名称设置的环境变量的名称，可选（如果存在）。
-
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."
}
}
}
}
条件 when
when指令允许Pipeline根据给定的条件确定是否执行该stage。when指令必须至少包含一个条件。如果when指令包含多个条件，则所有子条件必须都返回true，stage将会执行。这与子条件嵌套在一个allOf条件中相同（见下面的例子）。
更复杂的条件结构可使用嵌套条件建：not，allOf或anyOf。嵌套条件可以嵌套到任意深度。
| 是否必填 | 否 |
| 参数 | 没有 |
| 允许出现在 | 在stage指令内 |
内置条件
-
branch当正在构建的分支与给出的分支模式匹配时执行stage，例如：when { branch 'master' }。请注意，这仅适用于多分支Pipeline。
-
environment当指定的环境变量设置为给定值时执行stage，例如： when { environment name: 'DEPLOY_TO', value: 'production' }
-
expression当指定的Groovy表达式求值为true时执行stage，例如： when { expression { return params.DEBUG_BUILD } }
-
not当嵌套条件为false时执行stage。必须包含一个条件。例如：when { not { branch 'master' } }
-
allOf当所有嵌套条件都为真时，执行舞台。必须至少包含一个条件。例如：when { allOf { branch 'master'; environment name: 'DEPLOY_TO', value: 'production' } }
-
anyOf当至少一个嵌套条件为真时执行舞台。必须至少包含一个条件。例如：when { anyOf { branch 'master'; branch 'staging' } }
Jenkinsfile (Declarative Pipeline)
pipeline {
agent any
stages {
stage('Example Build') {
steps {
echo 'Hello World'
}
}
stage('Example Deploy') {
when {
branch 'production'
}
steps {
echo 'Deploying'
}
}
}
}
Jenkinsfile (Declarative Pipeline)
pipeline {
agent any
stages {
stage('Example Build') {
steps {
echo 'Hello World'
}
}
stage('Example Deploy') {
when {
branch 'production'
environment name: 'DEPLOY_TO', value: 'production'
}
steps {
echo 'Deploying'
}
}
}
}
Jenkinsfile (Declarative Pipeline)
pipeline {
agent any
stages {
stage('Example Build') {
steps {
echo 'Hello World'
}
}
stage('Example Deploy') {
when {
allOf {
branch 'production'
environment name: 'DEPLOY_TO', value: 'production'
}
}
steps {
echo 'Deploying'
}
}
}
}
Jenkinsfile (Declarative Pipeline)
pipeline {
agent any
stages {
stage('Example Build') {
steps {
echo 'Hello World'
}
}
stage('Example Deploy') {
when {
branch 'production'
anyOf {
environment name: 'DEPLOY_TO', value: 'production'
environment name: 'DEPLOY_TO', value: 'staging'
}
}
steps {
echo 'Deploying'
}
}
}
}
Jenkinsfile (Declarative Pipeline)
pipeline {
agent any
stages {
stage('Example Build') {
steps {
echo 'Hello World'
}
}
stage('Example Deploy') {
when {
expression { BRANCH_NAME ==~ /(production|staging)/ }
anyOf {
environment name: 'DEPLOY_TO', value: 'production'
environment name: 'DEPLOY_TO', value: 'staging'
}
}
steps {
echo 'Deploying'
}
}
}
}
顺序执行的stage（Sequential Stages）
声明性Pipeline中的stage可以按顺序声明待运行的stage列表。需要注意的是一个stage有且只能有一个 steps，parallel或者stages，stages是顺序执行的。stage内的stage无法进一步含有parallel或stages ，但他们允许使用stage的所有其他功能，包括 agent，tools，when等等。
pipeline {
agent none
stages {
stage('Non-Sequential Stage') {
agent {
label 'for-non-sequential'
}
steps {
echo "On Non-Sequential Stage"
}
}
stage('Sequential') {
agent {
label 'for-sequential'
}
environment {
FOR_SEQUENTIAL = "some-value"
}
stages {
stage('In Sequential 1') {
steps {
echo "In Sequential 1"
}
}
stage('In Sequential 2') {
steps {
echo "In Sequential 2"
}
}
}
}
}
}
并行的stage（Parallel）
声明性Parallel中的stage可以在parallel块中声明多个嵌套stage，这些stage将并行执行。需要注意的是一个stage有且只能有一个steps，stages或parallel。嵌套的stages本身不能包含其他parallelstage，但在其他方面的行为与stage相同，包括顺序执行的stage列表stages。任何包含parallel的stage都不能包含agent或者tools，因为那些和steps没有关系。
此外，您可以通过添加failFast true到包含parallel的stage中，使得其中一个失败时中止所有parallel内的stage。
pipeline {
agent any
stages {
stage('Non-Parallel Stage') {
steps {
echo 'This stage will be executed first.'
}
}
stage('Parallel Stage') {
when {
branch 'master'
}
failFast true
parallel {
stage('Branch A') {
agent {
label "for-branch-a"
}
steps {
echo "On Branch A"
}
}
stage('Branch B') {
agent {
label "for-branch-b"
}
steps {
echo "On Branch B"
}
}
stage('Branch C') {
agent {
label "for-branch-c"
}
stages {
stage('Nested 1') {
steps {
echo "In stage Nested 1 within Branch C"
}
}
stage('Nested 2') {
steps {
echo "In stage Nested 2 within Branch C"
}
}
}
}
}
}
}
}
步骤 Steps
声明性Pipeline可以使用“ Pipeline步骤”引用中记录的所有可用步骤 ，其中包含一个完整的步骤列表，并附加以下列出的步骤，仅在声明性Pipeline中支持。
脚本 script
script步骤需要一个script Pipeline，并在声明性Pipeline中执行。对于大多数场景，声明Pipeline中的script步骤不是必须的，但它可以提供一个有用的“escape hatch”。量大的或者复杂的script块应该转移到共享库中。
Jenkinsfile (Declarative Pipeline)
pipeline {
agent any
stages {
stage('Example') {
steps {
echo 'Hello World'
script {
def browsers = ['chrome', 'firefox']
for (int i = 0; i < browsers.size(); ++i) {
echo "Testing the ${browsers[i]} browser"
}
}
}
}
}
}
Scripted Pipeline
Scripted Pipeline，如声明式Pipeline，构建在底层Pipeline子系统之上。不像声明式Pipeline，Scripted Pipeline是一个基于Groovy构建的，通用、高效的DSL。由Groovy语言提供的大多数功能都提供给Scripted Pipeline的用户，这意味着它是一个非常富有表现力和灵活性的工具，可以通过这些工具来创建持续构建的Pipeline。
Flow Control
Scripted Pipeline从顶部顺序执行，与Jenkinsfile Groovy或其他语言中的大多数传统Scripted一样。因此，提供流量控制取决于Groovy表达式，例如 if/else条件，例如：
Jenkinsfile (Scripted Pipeline)
node {
stage('Example') {
if (env.BRANCH_NAME == 'master') {
echo 'I only execute on the master branch'
} else {
echo 'I execute elsewhere'
}
}
}
可以管理Scripted Pipeline流控制的另一种方式是使用Groovy的异常处理支持。当步骤由于任何原因而导致异常时。处理错误行为必须使用Groovy 中的try/catch/finally块，例如：
Jenkinsfile (Scripted Pipeline)
node {
stage('Example') {
try {
sh 'exit 1'
}
catch (exc) {
echo 'Something failed, I should sound the klaxons!'
throw
}
}
}
Steps
如“ 入门指南 ”所述，Pipeline最基本的部分是“步骤”。从根本上说，步骤告诉Jenkins 要做什么，并且作为Declarative和Scripted Pipeline语法的基本构建块。
Scripted Pipeline并没有介绍这是专门针对它的语法的任何步骤; Pipeline步骤参考 ，其中包含Pipeline和插件提供的完整步骤列表。
与Groovy的区别
为了提供持久性（运行中的Pipeline可以在重新启动Jenkins主站后保留），Scripted Pipeline必须将数据序列化到master节点。由于这个设计要求，一些Groovy语法如collection.each { item -> /* perform operation */ }没有完全支持。有关 更多信息，请参见 JENKINS-27421和 JENKINS-26481。
语法比较
当Jenkins Pipeline首次创建时，Groovy被选为执行引擎。Jenkins已经使用嵌入式Groovy引擎很长时间，为管理员和用户提供高级脚本功能。此外，Jenkins Pipeline的实现者发现Groovy是建立“Scripted Pipeline”DSL的坚实基础。
由于它是一个功能齐全的编程环境，Scripted Pipeline为Jenkins用户提供了极大的灵活性和可扩展性。Groovy学习曲线通常不适用于给定团队的所有成员，因此，创建声明性Pipeline是为了创作Jenkins Pipeline提供一个更简单和更有见解的语法。
两者基本上是底层相同的Pipeline 子系统。它们都是“Pipeline代码”的持久实现。他们都能够使用Pipeline内置的插件或插件提供的步骤。两者都可以利用共享库
不同之处在于语法和灵活性。声明性限制了用户具有更严格和预定义结构的可用性，使其成为更简单连续输送Pipeline的理想选择。脚本化提供了极少的限制，因为Groovy本身只能对结构和语法进行限制，而不是任何Pipeline专用系统，使其成为高级用户和具有更复杂要求的用户的理想选择。顾名思义，Declarative Pipeline鼓励声明式编程模型。 尽管Scripted Pipeline遵循更命令性的编程模型。
Pipeline stages中的stage含有stages
认真看，可以看到这些特点。
所有的stage,都会内嵌在最外层的stages{…}
一个stage{…}下可以内嵌有且只有一个stages{…}
多层嵌套只支持在最后一个stage{…}里面
嵌套越多越复杂，最简单就是观察每一个stage的大括号的范围
原则上，我们尽量少写嵌套的stage{…}，写了嵌套就意味很难维护。但是有时候，由于业务逻辑需要，和stage{…}组织结构好看，我们会写嵌套，嵌套里面可能存在顺序和平行的stage{…} 前面我们演示的demo都是顺序，也就是一个接着一个执行
pipeline {
agent none
stages {
stage('11111111') {
steps {
echo "11111111"
}
}
stage('22222') {
stages {
stage('222222aaaaa1') {
steps {
echo "222222aaaaa1"
}
}
stage('In 222222aaaa2') {
steps {
echo "222222aaaa2"
}
}
}
}
stage('33333') {
steps {
echo "33333"
}
}
}
}
并行stage{…}需要用到指令paraller, 有一个paraller{…} 里面包含多个stage{…},最后一个stage{…}内部支持嵌套多个stages{…}。在paraller{…}如果要设置只要里面有一个stage{…}运行失败就强制停止，可以使用表达式failFast true 来条件控制。
并行stage{…}举例：
pipeline {
agent any
stages {
stage('Non-Parallel Stage') {
steps {
echo 'This stage will be executed first.'
}
}
stage('Parallel Stage') {
failFast true
parallel {
stage('并行一') {
steps {
echo "并行一"
}
}
stage('并行二') {
steps {
echo "并行二"
}
}
stage('并行三') {
stages {
stage('Nested 1') {
steps {
echo "In stage Nested 1 within Branch C"
}
}
stage('Nested 2') {
steps {
echo "In stage Nested 2 within Branch C"
}
}
}
}
}
}
}
}
pipeline {
agent any
stages {
stage('Non-Parallel Stage') {
steps {
echo 'This stage will be executed first.'
}
}
stage('Parallel Stage') {
failFast true
parallel {
stage('并行一') {
steps {
echo "并行一"
}
}
stage('并行二') {
steps {
echo "并行二"
}
}
stage('并行三') {
stages {
stage('Nested 1') {
steps {
echo "In stage Nested 1 within Branch C"
}
}
stage('Nested 2') {
steps {
echo "In stage Nested 2 within Branch C"
}
}
}
}
}
}
}
}
关于这个并行，我创建了一个jenkins job，跑一下就可以帮助你了解。
并行1 并行2 并行3 三个stage之间的关系是并行的，上面截图显示都执行成功。这里我们测试一下如果并行二发生报错，会发生生成。在并行二里面的echo 改成echo1，再次运行。
由于我们添加了代码failFast true，但是并行二这个stage发生了报错。本来并行1 并行2 并行3下面两个嵌套的stage都在同一时间并发执行，但是这个job最终的结果是aborted, 从控制台日志或者UI显示灰色能看出来确实是中止了。
总结一下，paraller{…}这个要会使用，使用这个表示并行执行里面的多个stage。这里举例一下这个使用场景，例如我有一个模块的代码分别要在windows 和mac 和linux上三种环境下去测试。那么我可以提前准备好三个环境的agent node机器，然后一套环境写一个stage，把这三个stage都放在paraller{…}里面，让三个并行测试。paraller{…}上面一层这个stage名称就可以叫xxx模块兼容性测试。因为这三个环境都同等重要，你就可以设置failFast true，只要有一个不通过，就中止运行pipeline下面的代码。关于嵌套，非不得已，不要去使用，确实让其他人不好读代码和不好维护。
流程控制
由于pipeline是基于groovy语言开发的，所以支持在pipeline{...}代码块写流程控制语句代码和循环代码。原则上，大部分java和groovy的语法都可以在pipeline上得到很好的处理，但是还是有一些是不好兼容的，所以，Jenkins特意为了更好使用pipeline，开发了一些工具类，方便我们更好地在step中处理各种需求。接下来，我要带大家一起学习https://jenkins.io/doc/pipeline/steps/pipeline-utility-steps/
这个页面的一些常用的工具类的使用，算是一个实战练习过程吧。pipeline语法就学习完了，对了还有一种script pipeline我不打算介绍，从头到尾我们都在学习更容易维护和直观的Declarative Pipeline模式。下面写一个if控制语句来展开接下来我们要实战的练习。
pipeline {
agent any
stages {
stage('flow control') {
steps {
script {
if ( 10 == 10) {
println "pass"
}else {
println "failed"
}
}
}
}
}
}
------------------------- A little Progress a day makes you a big success... ----------------------------
