Jenkinspipeline:pipeline使⽤之语法详解
⼀、引⾔
  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⼀样,都可以⽤来编写脚本。
  相关资料:
  从检索的资料来看,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 { additi
onalBuildArgs '--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'
}
git使用详解
}
}
}
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'
}
}
}
}
options
options指令允许在Pipeline本⾝内配置Pipeline专⽤选项。Pipeline本⾝提供了许多选项,例如buildDiscarder,但它们也可能由插件提供,例如 timestamps。
可⽤选项
  buildDiscarder
    pipeline保持构建的最⼤个数。例如:options { buildDiscarder(logRotator(numToKeepStr: '1')) }
  disableConcurrentBuilds
    不允许并⾏执⾏Pipeline,可⽤于防⽌同时访问共享资源等。例如:options { disableConcurrentBuilds() }
  skipDefaultCheckout
    默认跳过来⾃源代码控制的代码。例如:options { skipDefaultCheckout() }
  skipStagesAfterUnstable
    ⼀旦构建状态进⼊了“Unstable”状态,就跳过此stage。例如:options { skipStagesAfterUnstable() }
  timeout
    设置Pipeline运⾏的超时时间。例如:options { timeout(time: 1, unit: 'HOURS') }
  retry
    失败后,重试整个Pipeline的次数。例如:options { retry(3) }
  timestamps
    预定义由Pipeline⽣成的所有控制台输出时间。例如:options { timestamps() }
pipeline {
agent any
options {
timeout(time: 1, unit: 'HOURS')
}
stages {
stage('Example') {
steps {
echo 'Hello World'
}
}
}
} 
parameters
parameters指令提供⽤户在触发Pipeline时的参数列表。这些参数值通过该params对象可⽤于Pipeline步骤,具体⽤法如下
可⽤参数
  string
    A parameter of a string type, for example: parameters { string(name: 'DEPLOY_ENV', defaultValue: 'staging', description: '') }
  booleanParam
    A boolean parameter, for example: parameters { booleanParam(name: 'DEBUG_BUILD', defaultValue: true, description: '') }
  ⽬前只⽀持[booleanParam, choice, credentials, file, text, password, run, string]这⼏种参数类型,其他⾼级参数化类型还需等待社区⽀持。
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}"
}
}
}
}
triggers
triggers指令定义了Pipeline⾃动化触发的⽅式。对于与源代码集成的Pipeline,如GitHub或BitBucket,triggers可能不需要基于webhook的集成也已经存在。⽬前只有两个可⽤的触发器:cron和pollSCM。
cron
  接受⼀个cron风格的字符串来定义Pipeline触发的常规间隔,例如: triggers { cron('H 4/* 0 0 1-5') }
pollSCM
  接受⼀个cron风格的字符串来定义Jenkins检查SCM源更改的常规间隔。如果存在新的更改,则Pipeline将被重新触发。例如:triggers { pollSCM('H 4/* 0 0 1-5') }
pipeline {
agent any
triggers {
cron('H 4/* 0 0 1-5')
}
stages {
stage('Example') {
steps {
echo 'Hello World'
}
}
}
}
stage
stage指令在stages部分中,应包含stop部分,可选agent部分或其他特定于stage的指令。实际上,Pipeline完成的所有实际⼯作都将包含在⼀个或多个stage指令中。
pipeline {
agent any
stages {

版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198,我们将在24小时内删除。