一、引言
Jenkins 2.0的到来，pipline进入了视野，jenkins2.0的核心特性. 也是最适合持续交付的feature。
简单的来说，就是把Jenkins1.0版本中，Project中的相关配置信息，如SVN/Git的配置，Parameter的配置等都变成Code，即Pipeline as Code。
随着pipeline交付流水线在团队中的推广，使用pipeline脚本的job也迅速增加。
优势：
-
- 通过写代码的形式配置Project，且Jenkins中内置了常用的steps。
- 实现了构建步骤代码化、构建过程视图化。
二、语法简介
Pipeline最基本的部分是“step”。基本上，step告诉Jenkins 要做什么，并且作为Declarative Pipeline和Scripted Pipeline语法的基本构建块。
Pipeline支持两种语法：Declarative Pipeline（在Pipeline 2.5中引入，结构化方式）和Scripted Pipeline，两者都支持建立连续输送的Pipeline。
选择Declarative Pipeline还是Scripted Pipeline
最开始的Pipeline plugin，支持的只有一种脚本类型，就是Scripted Pipeline；
Declarative Pipeline为Pipeline plugin在2.5版本之后新增的一种脚本类型，与原先的Scripted Pipeline一样，都可以用来编写脚本。
相关资料：
https://stackoverflow.com/questions/43484979/jenkins-scripted-pipeline-or-declarative-pipeline
http://jenkins-ci.361315.n4.nabble.com/Declarative-pipelines-vs-scripted-td4891792.html
从检索的资料来看，Declarative Pipeline 是后续Open Blue Ocean所支持的类型。相对而言，Declarative Pipeline比较简单，Declarative Pipeline中，也是可以内嵌Scripted Pipeline代码的。
为与BlueOcean脚本编辑器兼容，通常建议使用Declarative Pipeline的方式进行编写,从jenkins社区的动向来看，很明显这种语法结构也会是未来的趋势。
三、Declarative Pipeline
Declarative Pipeline是Jenkins Pipeline 的一个相对较新的补充， 它在Pipeline子系统之上提出了一种更为简化和有意义的语法。
所有有效的Declarative Pipeline必须包含在一个pipeline块内，例如：
pipeline { /* insert Declarative Pipeline here */ }
Declarative Pipeline中的基本语句和表达式遵循与Groovy语法相同的规则 ，但有以下例外：
- a.Pipeline的顶层必须是块，具体来说是：pipeline { }
- b.没有分号作为语句分隔符。每个声明必须在自己的一行
- c.块只能包含Sections, Directives, Steps或赋值语句。
- d.属性引用语句被视为无参方法调用。所以例如，输入被视为input（）
1.Sections（章节）
Declarative Pipeline里的Sections通常包含一个或多个Directives或 Steps
agent
agent部分指定整个Pipeline或特定阶段将在Jenkins环境中执行的位置，具体取决于该agent 部分的放置位置。该部分必须在pipeline块内的顶层定义 ，但stage级使用是可选的。
为了支持Pipeline可能拥有的各种用例，该agent部分支持几种不同类型的参数。这些参数可以应用于pipeline块的顶层，也可以应用在每个stage指令内。
参数
any
在任何可用的agent 上执行Pipeline或stage。例如：agent any
none
当在pipeline块的顶层使用none时，将不会为整个Pipeline运行分配全局agent ，每个stage部分将需要包含其自己的agent部分。
label
使用提供的label标签，在Jenkins环境中可用的代理上执行Pipeline或stage。例如：agent { label ‘my-defined-label‘ }
node
agent { node { label ‘labelName‘ } }，等同于 agent { label ‘labelName‘ }，但node允许其他选项（如customWorkspace）。
docker
定义此参数时，执行Pipeline或stage时会动态供应一个docker节点去接受Docker-based的Pipelines。 docker还可以接受一个args，直接传递给docker run调用。例如：agent { docker ‘maven:3-alpine‘ }或
docker
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‘ } }。您可以通过docker build ...使用additionalBuildArgs选项，如agent { dockerfile { additionalBuildArgs ‘--build-arg foo=bar‘ } }。
参数
any
在任何可用的agent 上执行Pipeline或stage。例如：agent any
none
当在pipeline块的顶层使用none时，将不会为整个Pipeline运行分配全局agent ，每个stage部分将需要包含其自己的agent部分。
label
使用提供的label标签，在Jenkins环境中可用的代理上执行Pipeline或stage。例如：agent { label ‘my-defined-label‘ }
node
agent { node { label ‘labelName‘ } }，等同于 agent { label ‘labelName‘ }，但node允许其他选项（如customWorkspace）。
docker
定义此参数时，执行Pipeline或stage时会动态供应一个docker节点去接受Docker-based的Pipelines。 docker还可以接受一个args，直接传递给docker run调用。例如：agent { docker ‘maven:3-alpine‘ }或
docker
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‘ } }。您可以通过docker build ...使用additionalBuildArgs选项，如agent { dockerfile { additionalBuildArgs ‘--build-arg foo=bar‘ } }。
常用选项
这些是可以应用于两个或多个agent的选项。除非明确定义，否则不需要。
label
一个字符串。标记在哪里运行pipeline或stage
此选项适用于node，docker和dockerfile，并且 node是必需的。
customWorkspace
一个字符串。自定义运行的工作空间内。它可以是相对路径，在这种情况下，自定义工作区将位于节点上的工作空间根目录下，也可以是绝对路径。例如：
agent {
node {
label ‘my-defined-label‘
customWorkspace ‘/some/other/path‘
}
}
reuseNode
一个布尔值，默认为false。如果为true，则在同一工作空间中。
此选项适用于docker和dockerfile，并且仅在 individual stage中使用agent才有效。
pipeline {
//Execute all the steps defined in this Pipeline within a newly created container of the given name and tag (maven:3-alpine).
agent { docker ‘maven:3-alpine‘ }
stages {
stage(‘Example Build‘) {
steps {
sh ‘mvn -B clean verify‘
}
}
}
}
pipeline {
agent none
stages {
stage(‘Example Build‘) {
agent { docker ‘maven:3-alpine‘ }
steps {
echo ‘Hello, Maven‘
sh ‘mvn --version‘
}
}
stage(‘Example Test‘) {
agent { docker ‘openjdk:8-jre‘ }
steps {
echo ‘Hello, JDK‘
sh ‘java -version‘
}
}
}
}
post
定义Pipeline或stage运行结束时的操作。post-condition块支持post部件：always，changed，failure，success，unstable，和aborted。这些块允许在Pipeline或stage运行结束时执行步骤，具体取决于Pipeline的状态。
conditions项：
always
运行，无论Pipeline运行的完成状态如何。
changed
只有当前Pipeline运行的状态与先前完成的Pipeline的状态不同时，才能运行。
failure
仅当当前Pipeline处于“失败”状态时才运行，通常在Web UI中用红色指示表示。
success
仅当当前Pipeline具有“成功”状态时才运行，通常在具有蓝色或绿色指示的Web UI中表示。
unstable
只有当前Pipeline具有“不稳定”状态，通常由测试失败，代码违例等引起，才能运行。通常在具有黄色指示的Web UI中表示。
aborted
只有当前Pipeline处于“中止”状态时，才会运行，通常是由于Pipeline被手动中止。通常在具有灰色指示的Web UI中表示。
pipeline {
agent any
stages {
stage(‘Example‘) {
steps {
echo ‘Hello World‘
}
}
}
post {
always {
echo ‘I will always say Hello again!‘
}
}
}
stages
包含一个或多个stage的序列，Pipeline的大部分工作在此执行。建议stages至少包含至少一个stage指令，用于连接各个交付过程，如构建，测试和部署等。
steps
steps包含一个或多个在stage块中执行的step序列。
pipeline {
agent any
stages {
stage(‘Example‘) {
steps {
echo ‘Hello World‘
}
}
}
}
2.Directives （指令）
environment
environment指令指定一系列键值对，这些键值对将被定义为所有step或stage-specific step的环境变量，具体取决于environment指令在Pipeline中的位置。
该指令支持一种特殊的方法credentials()，可以通过其在Jenkins环境中的标识符来访问预定义的凭据。
对于类型为“Secret Text”的凭据，该 credentials()方法将确保指定的环境变量包含Secret Text内容；对于“标准用户名和密码”类型的凭证，指定的环境变量将被设置为username:password。
pipeline {
agent any
environment {
CC = ‘clang‘
}
stages {
stage(‘Example‘) {
environment {
AN_ACCESS_KEY = credentials(‘my-prefined-secret-text‘)
}
steps {
sh ‘printenv‘
}
}
}
}