这里写目录标题
- pipeline的组成
- 1、pipeline最简单结构
- 1.1、pipeline
- 1.2、stages
- 1.3、stage
- 1.4、steps
- 1.5、agent
- 2、post
- 3、pipeline支持的命令
- 3.1、environment
- 3.2、tools
- 3.3、input
- 3.4、options
- 3.5、parameters
- 3.6、parallel
- 3.7、triggers
- 3.8、when
pipeline的组成
1、pipeline最简单结构
pipeline的必须部分有以下五个，少一个都不行都会报错。
1.1、pipeline
代表整条流水线，包含整条流水线的逻辑。
1.2、stages
流水线中多个stage的容器。stages部分至少包含一个stage。
1.3、stage
阶段，代表流水线的阶段。每个阶段必须有名称。。
1.4、steps
代表阶段中的一个或者多个具体步骤（step）的容器。steps部分至少一个步骤。
1.5、agent
指定流水线的执行节点（Jenkins agent）
参数：
- any: 在任何可用的agent 上执行Pipeline或stage。例如：agent any
- none: 当在pipeline块的顶层使用none时，将不会为整个Pipeline运行分配全局agent ，每个stage部分将需要包含其自己的agent部分。
- label: 使用有label标签的agent，例如：agent
- node: agent { node { label ‘labelName’ } }，等同于 agent { label ‘labelName’ }，但node允许其他选项（如customWorkspace）。
- docker: 动态供应一个docker节点去执行pipeline或stage，docker还可以接受一个args，直接传递给docker run调用。
2、post
post部分包含的是在整个pipeline或阶段完成后一些附加的步骤。post部分是可选的，所以并不包含在pipeline最简结构中。但这并不代表它作用不大。根据pipeline或阶段的完成状态，post部分分成多种条件块，包括：
- always：不论当前完成状态是什么都执行。
- success：当前完成状态为成功时运行。
- failure：当前完成状态为失败时执行。
- unstable：当前完成状态为不稳定时执行。
- changed：只要当前完成状态与上一次完成状态不同就执行。
- fixed：上一次完成状态为失败或不稳定（unstable），当前完成状态为成功时执行。
- aborted：当前执行结果是中止状态时（一般为人为中止）执行。
- cleanup：清理条件块。不论当前完成状态是什么，在其他所有条件块执行完成后都执行
- regression：上一次完成状态为成功，当前完成状态为失败、不稳定或中止（aborted）时执行。
3、pipeline支持的命令
3.1、environment
用户设置环境变量，可以定义在stage或者pipeline部分
定义Pipeline或stage运行时的环境变量
不是必须出现的指令
无参数
该environment指令指定一系列键值对，这些对值将被定义为所有步骤的环境变量或阶段特定步骤，具体取决于environment指令位于pipeline中的位置。
例如
pipeline {
agent {
node{
label 'docker_node'
customWorkspace "myWorkspace"
}
}
environment {
hlw = 'hello world'
}
3.2、tools
可定义在pipeline或stage部分。它会自动下载并安装我们指定的工具，并将其加入PATH变量中。如果agent none指定，则将其忽略。
pipeline {
agent any
tools {
maven 'apache-maven-3.0.1'
}
stages {
stage('Example') {
steps {
sh 'mvn --version'
}
}
}
}
3.3、input
3.4、options
options ：该options指令允许在Pipeline本身内配置Pipeline专用选项。Pipeline提供了许多这些选项
不是必须出现的指令
常用选项
- buildDiscarder: pipeline保持构建的最大个数。例如：options
- disableConcurrentBuilds: 不允许并行执行Pipeline,可用于防止同时访问共享资源等。例如：options
- skipDefaultCheckout: 默认跳过来自源代码控制的代码。例如：options
- skipStagesAfterUnstable: 一旦构建状态进入了“Unstable”状态，就跳过此stage。例如：options
- timeout: 设置Pipeline运行的超时时间。例如：options
- retry: 失败后，重试整个Pipeline的次数。例如：options
- timestamps: 预定义由Pipeline生成的所有控制台输出时间。例如：options
pipeline{
agent {
node{
label 'docker_node'
customWorkspace "pipelineWorkspace"
}
}
options {
timeout(time: 10,unit:"SECONDS") //构建超过10s,就会超时
buildDiscarder(logRotator(numToKeepStr:"2")) //最多保留2个最新的构建
retry(5) //失败后尝试运行5次
}
3.5、parameters
parameters ：定义pipeline 的专有参数列表
不是必须出现的指令
- 支持数据类型：booleanParam, choice, credentials, file, text, password, run, string
类似参数化构建的选项
代码举例
parameters {
string(name: 'PERSON', defaultValue: 'Jenkins', description: '输入的文本参数')
choice(name: 'CHOICE', choices: ['One', 'Two', 'Three'], description: 'Pick something')
}
代码举例
pipeline {
agent any
parameters {
string(name: 'Version',defaultValue:'1.1.1',description: '版本号')
text name: 'index_monitor',defaultValue: 'index_monitor',description: '综合平台首页数据监控'
booleanParam(name: 'ifFlag',defaultValue: true, description: 'isFlag is True')
choice name: 'env',choices: ["prod","test"], description: '环境'
}
}
3.6、parallel
声明性Parallel的代码块中的可以嵌套多个stage，从而让多个stage任务并行执行。
注意：
一个stage有且只能有一个steps，stages或parallel
嵌套的stages本身不能包含其他parallel stage
但在其他方面的行为与stage相同
任何包含parallel的stage都不能包含agent或者tools
案例
pipeline {
agent any
stages {
stage('s1') {
steps {
sh 'echo s1'
}
}
stage('s2') {
parallel {
stage('parallel-1'){
steps{
echo "parallel-1"
}
}
stage('parallel-2'){
steps{
echo "parallel-2"
}
}
}
}
stage('s3') {
steps {
sh 'echo s3'
}
}
}
}
运行结果
案例
pipeline {
agent any
stages {
stage('Non-Parallel Stage') {
steps {
echo 'This stage will be executed first.'
}
}
stage('Parallel Stage') {
when {
branch 'master'
}
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"
}
}
}
}
}
}
3.7、triggers
用于定义执行pipeline的触发器。• when：当满足when定义的条件时，阶段才执行。
triggers指令定义了Pipeline自动化触发的方式。对于与源代码集成的Pipeline，如GitHub或BitBucket，triggers可能不需要基于webhook的集成也已经存在。目前只有两个可用的触发器：cron和pollSCM。
- cron: 接受一个cron风格的字符串来定义Pipeline触发的常规间隔，例如： triggers
- pollSCM: 接受一个cron风格的字符串来定义Jenkins检查SCM源更改的常规间隔。如果存在新的更改，则Pipeline将被重新触发。例如：triggers
案例
// Declarative //
pipeline {
agent any
triggers {
cron('H */4 * * 1-5')
'''
每15分钟构建一次：H/15 * * * * 或*/5 * * * *
每天8点构建一次：H 8 * * *
每天8点~17点，两小时构建一次：H 8-17/2 * * *
周一到周五，8点~17点，两小时构建一次：H 8-17/2 * * 1-5
每月1号、15号各构建一次，除12月：H H 1,15 1-11 *
第1列分钟1～59
第2列小时0～23
第3列日1～31
第4列月1～12
第5列星期0～7(0和7表示星期日)
'''
}
stages {
stage('Example') {
steps {
echo 'Hello World'
}
}
}
}
3.8、when
when指令允许Pipeline根据给定的条件确定是否执行该阶段。该when指令必须至少包含一个条件。如果when指令包含多个条件，则所有子条件必须为stage执行返回true。这与子条件嵌套在一个allOf条件中相同。
内置条件
- branch: 当正在构建的分支与给出的分支模式匹配时执行，例如：when { branch ‘master’ }。请注意，这仅适用于多分支Pipeline。
- environment: 当指定的环境变量设置为给定值时执行，例如： when
- expression: 当指定的Groovy表达式求值为true时执行，例如： when { expression { return params.DEBUG_BUILD } }
- not: 当嵌套条件为false时执行。必须包含一个条件。例如：when { not { branch ‘master’ } }
- allOf: 当所有嵌套条件都为真时执行。必须至少包含一个条件。例如：when { allOf { - branch ‘master’; environment name: ‘DEPLOY_TO’, value: ‘production’ } }
- anyOf: 当至少一个嵌套条件为真时执行。必须至少包含一个条件。例如：when { anyOf { branch ‘master’; branch ‘staging’ } }
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'
}
}
}
}
