https://jenkins.io/zh/doc/book/pipeline/syntax/
https://blog.csdn.net/taishanduba/article/details/61423121
https://www.cnblogs.com/kevingrace/p/6022447.html
通用规则
- Agent
- Agent通常是一个机器或容器，它连接到Jenkins主机，并在主控器指导时执行任务。
- Artifact
-
在Build或Pipeline 运行期间生成的不可变文件，该文件归档到Jenkins Master上以供用户随后检索。
- Build
-
项目 单次执行的结果
- Cloud
-
提供动态代理 配置和分配的系统配置，例如由Azure VM Agents 或 Amazon EC2插件提供的配置和分配 。
- Core
-
主要的Jenkins应用程序（
jenkins.war）提供了 可以构建Plugins的基本Web UI，配置和基础。 - Downstream
-
配置Pipeline或项目时被触发作为一个单独的Pipeline或项目的执行的一部分。
- Executor
-
用于执行由节点上的Pipeline或 项目定义的工作的插槽。节点可以具有零个或多个配置的执行器，其对应于在该节点上能够执行多少并发项目或Pipeline。
- Fingerprint
-
考虑全局唯一性的哈希追踪跨多个Pipeline或项目的工件或其他实体 的使用 。
- Folder
-
类似于文件系统上的文件夹的Pipeline和/或 项目 的组织容器。
- Item
-
Web UI中的实体对应于：Folder, Pipeline, or Project.
- Job
-
一个不推荐的术语，与项目同义。
- Label
-
用于分组代理的用户定义的文本，通常具有类似的功能或功能。例如
linux对于基于Linux的代理或docker适用于支持Docker的代理。 - Master
-
存储配置，加载插件以及为Jenkins呈现各种用户界面的中央协调过程。
- Node
-
作为Jenkins环境的一部分并能够执行Pipeline或项目的机器。无论是the Master还是Agents都被认为是Nodes。
- Project
-
用户配置的Jenkins应该执行的工作描述，如构建软件等。
- Pipeline
-
用户定义的连续输送Pipeline模型，以便更多阅读本手册中的“ Pipeline”一章。
- Plugin
-
与Jenkins Core分开提供的Jenkins功能扩展。
- Publisher
-
完成发布报告，发送通知等的所有配置步骤后的 构建的 一部分。
- Stage
-
stage是Pipeline的一部分，用于定义整个Pipeline的概念上不同的子集，例如：“构建”，“测试”和“部署”，许多插件用于可视化或呈现Jenkins Pipeline状态/进度。 - Step
-
单一任务从根本上讲，指的是Jenkins 在Pipeline或项目中做了什么。
- Trigger
-
触发新Pipeline运行或构建的标准。
- Update Center
-
托管插件和插件元数据的库存，以便在Jenkins内部进行插件安装。
- Upstream
-
配置的Pipeline或项目，其触发单独的Pipeline或项目作为其执行的一部分。
- Workspace
-
Noede文件系统上的一次性目录， 可以由Pipeline或项目完成工作。在Build或 Pipeline运行完成后，工作区通常会保留原样，除非在Jenkins Master上已经设置了特定的Workspace清理策略。
1.Freestyle project
这个是jenkins的基础功能,可以用它来执行各种构建任务,他只能构建在一个电脑上,如果没有太多的需求,这个job基本够用了,它包含了所有基础功能.
2.Pipeline
真实的工作环境有很多job，比如先编译，然后执行静态代码检查、单元测试、然后部署服务器、服务器重启、进行ui测试等。我们需要对这些job进行一些设置将它们的上下游关系配置好。这个时候就需要pipeline配置了.详细的可以参考这篇文章
3.External job
用来监视外部执行的job.
4.Multi-configuration project
可以让job跑在不同的机器上.这个需要添加机器(节点),流程的话可以参考这篇文章
后面还有一些,这里不一一介绍了,有需要的可以自己google.
我们选择最基础的freestyle创建一个job,点击ok按钮.
1）代码上线要经历四个场景：Dev开发环境-->Test测试环境-->Beta验收环境-->Online线上环境
Dev开发环境：开发人员在开发机上自行开发，开发后将代码上传到svn/git版本控制系统里。
Test测试环境：将代码从svn下载并同步到测试机（Test环境发版），通知测试同事进行上线前的业务测试。
Beta验收环境：测试同事测试ok后，将代码同步到Beta机上（Beta环境发版），然后通知产品/运营同事进行上线前的验收。
Online线上环境：待Beta验收ok后，再将代码同步到线上机器上，最终完成Online发版。
声明式和脚本化的流水线语法
Jenkinsfile 能使用两种语法进行编写 - 声明式和脚本化。
声明式和脚本化的流水线从根本上是不同的。 声明式流水线的是 Jenkins 流水线更近的特性:
-
相比脚本化的流水线语法，它提供更丰富的语法特性,
-
是为了使编写和读取流水线代码更容易而设计的。
然而，写到`Jenkinsfile`中的许多单独的语法组件(或者 "步骤"), 通常都是声明式和脚本化相结合的流水线。 在下面的 [pipeline-concepts] 和 [pipeline-syntax-overview] 了解更多这两种语法的不同。
Why Pipeline?
本质上，Jenkins 是一个自动化引擎，它支持许多自动模式。 流水线向Jenkins中添加了一组强大的工具, 支持用例 简单的持续集成到全面的CD流水线。通过对一系列的相关任务进行建模, 用户可以利用流水线的很多特性:
-
Code: 流水线是在代码中实现的，通常会检查到源代码控制, 使团队有编辑, 审查和迭代他们的交付流水线的能力。
-
Durable: 流水线可以从Jenkins的主分支的计划内和计划外的重启中存活下来。
-
Pausable: 流水线可以有选择的停止或等待人工输入或批准，然后才能继续运行流水线。
-
Versatile: 流水线支持复杂的现实世界的 CD 需求, 包括fork/join, 循环, 并行执行工作的能力。
-
Extensible:流水线插件支持扩展到它的DSL [1]的惯例和与其他插件集成的多个选项。
然而， Jenkins一直允许以将自由式工作链接到一起的初级形式来执行顺序任务, [4] 流水线使这个概念成为了Jenkins的头等公民。
构建一个的可扩展的核心Jenkins值, 流水线也可以通过 Pipeline Shared Libraries 的用户和插件开发人员来扩展。 [5]
下面的流程图是一个 CD 场景的示例，在Jenkins中很容易对该场景进行建模:
流水线概念
下面的概念是Jenkins流水线很关键的一方面 , 它与流水线语法紧密相连 (参考 overview below).
阶段
stage 块定义了在整个流水线的执行任务的概念性地不同的的子集(比如 "Build", "Test" 和 "Deploy" 阶段), 它被许多插件用于可视化 或Jenkins流水线目前的 状态/进展. [6]
步骤
本质上 ，一个单一的任务, a step 告诉Jenkins 在特定的时间点要做_what_ (或过程中的 "step")。 举个例子,要执行shell命令 ，请使用 sh 步骤: sh 'make'。当一个插件扩展了流水线DSL, [1] 通常意味着插件已经实现了一个新的 step。
流水线语法概述
声明式流水线基础
在声明式流水线语法中, pipeline 块定义了整个流水线中完成的所有的工作。
pipeline {
agent any #1
stages {
stage('Build') { #2
steps {
// #3
}
}
stage('Test') { #4
steps {
// #5
}
}
stage('Deploy') { #6
steps {
// #7
}
}
}
}| 1 | 在任何可用的代理上，执行流水线或它的任何阶段。 |
| 2 | 定义 "Build" 阶段。 |
| 3 | 执行与 "Build" 阶段相关的步骤。 |
| 4 | 定义"Test" 阶。 |
| 5 | 执行与"Test" 阶段相关的步骤。 |
| 6 | 定义 "Deploy" 阶段。 |
| 7 | 执行与 "Deploy" 阶段相关的步骤。 |
脚本化流水线基础
在脚本化流水线语法中, 一个或多个 node 块在整个流水线中执行核心工作。 虽然这不是脚本化流水线语法的强制性要求, 但它限制了你的流水线的在`node`块内的工作做两件事:
-
通过在Jenkins队列中添加一个项来调度块中包含的步骤。 节点上的执行器一空闲, 该步骤就会运行。
-
创建一个工作区(特定为特定流水间建立的目录)，其中工作可以在从源代码控制检出的文件上完成。
Caution: 根据你的 Jenkins 配置,在一系列的空闲后，一些工作区可能不会自动清理 。参考 JENKINS-2111 了解更多信息。
Jenkinsfile (Scripted Pipeline)
node { #1
stage('Build') { #2
// #3
}
stage('Test') { #4
// #5
}
stage('Deploy') { #6
// #7
}
}
|
1 |
在任何可用的代理上，执行流水线或它的任何阶段。 |
| 2 | 定义 "Build" 阶段。 stage blocks 在脚本化流水线语法中是可选的。 然而, 在脚本化流水线中实现`stage` 块 ，可以清楚的显示Jenkins UI中的每个`stage`的任务子集。 |
| 3 | 执行与 "Build" 阶段相关的步骤。 |
| 4 | 定义 "Test" 阶段。 |
| 5 | 执行与 "Test" 阶段相关的步骤。 |
| 6 | 定义 "Deploy" 阶段。 |
| 7 | 执行与 "Deploy" 阶段相关的步骤。 |
流水线示例
这有一个使用声明式流水线的语法编写的`Jenkinsfile` 文件 - 可以通过点击下面 Toggle Scripted Pipeline 链接来访问它的等效的脚本化语法：
pipeline { #1
agent any #2
stages {
stage('Build') { #3
steps { #4
sh 'make' #5
}
}
stage('Test'){
steps {
sh 'make check'
junit 'reports/**/*.xml' #6
}
}
stage('Deploy') {
steps {
sh 'make publish'
}
}
}
}| 1 | pipeline 是声明式流水线的一种特定语法，他定义了包含执行整个流水线的所有内容和指令的 "block" 。 |
| 2 | agent是声明式流水线的一种特定语法，它 指示 Jenkins 为整个流水线分配一个执行器 (在节点上)和工作区。 |
| 3 | stage 是一个描述 stage of this Pipeline的语法块。在 Pipeline syntax 页面阅读更多有关声明式流水线语法的`stage`块的信息。如 above所述, 在脚本化流水线语法中，stage 块是可选的。 |
| 4 | steps 是声明式流水线的一种特定语法，它描述了在这个`stage`中要运行的步骤。 |
| 5 | sh 是一个执行给定的shell命令的流水线 step (由 Pipeline: Nodes and Processes plugin提供) 。 |
| 6 | junit 是另一个聚合测试报告的流水线 step (由 JUnit plugin提供)。 |
| 7 | node 是脚本化流水线的一种特定语法，它指示 Jenkins 在任何可用的代理/节点上执行流水线 (和包含在其中的任何阶段)这实际上等效于 声明式流水线特定语法的`agent`。 |
1.General:一般设置
Project name:项目名称
Description:项目描述,多人写作请一定要加上
Discard old builds:（discard 丢弃）该选项配置如何抛弃旧的构建
每次构建相关的文件都会保存下来，将会渐渐耗光磁盘空间，为此提供两种方式供选择：
- Days to keep builds：保留N天之内的构建文件
- Max # of builds to keep：保留最多#个最近构建的相关文件
- days to keep artifcts 指定产品保留时间,但是log,历史记录会保留
- builds to keep with artifacts 保留最近几个构建的产品
This project is parameterized（参数化构建过程）:可以设置用户可输入的参数,没有输入则使用默认值,有字符串,多行字符串,布尔值等可以设置.wiki
Throttle builds:设置两个build任务之间最小间隔和同一个时间内最大任务数量
Disable this project:停止这个job,当例如源码不可用时,可以暂时勾选这个停止build
Execute concurrent builds if necessary: 如果可以会并发执行build.勾选上后.如果有足够的线程池则会并发,否则不会.并发构建会在不同的workspace中.如果用户自己设置的workspace则不会分开,这个是有风险的.
Restrict where this project can be run: 设置是否必须在某个机器上运行.如果是分布式部署或者迁移job,注意移除或修改此项配置
Quiet period:配置等待未发生提交变化的时间. 由于 jenkins检测到代码变化时,就自动立即构建，但是有些情况下， 需要多次提交代码到版本控制系统上，此时,可能发生代码还没完整提交就开始构建,造成构建失败,为防止此种情况发生,可以配置值X,则jenkins会在代码变化后等待X秒,如果没在发生代码提交,才开始构建,保证稳定性。
Block build when downstream project is building:该选项当多个相关联的项目由一个提交所影响，但是它们必须以一个指定的顺序进行构建的时候非常有用。当你选择这个选项的时候，Jenkins将会在启动这个构建之前，完成任何上游构建Job； 例如使用pipes的时候
2.Source Code Management:源码管理
通过这里设置源码管理路径,这个与后面的轮询源码变化触发编译是成对的.不想设置或者后面有脚本可以自主管理可以选择none
Build Triggers:构建(编译,任务等等)触发时机
Trigger builds remotely (e.g., from scripts):外部通过url命令触发,拼接token和url就可以进行远程触发了
Build after other projects are built:监控其他job的构建状态,触发此job.如监听代码提交,然后触发UITest,静态分析等.
Build periodically:定时触发.选择 Build periodically,在 Schedule 中填写 0 * * * .第一个参数代表的是分钟 minute,取值 0~59;第二个参数代表的是小时 hour,取值 0~23;第三个参数代表的是天 day,取值 1~31;第四个参数代表的是月 month,取值 1~12;最后一个参数代表的是星期 week,取值 0~7，0 和 7 都是表示星期天。所以 0 * * * 表示的就是每个小时的第 0 分钟执行一次构建。举个例子:每周六10点构建 0 10 * * 6,0-0分钟, 10-10点 -任意天 -任务月份 6-周六, 0可以改为H.
Poll SCM:定时感知代码分支是否有变化,如果有变化的话,执行一次构建.示例：H/5 * * * * 每五分钟去检查一下远程仓库,看代码是否发生变化。
**GitHub hook trigger for GITScm polling:**hookplugin检测到源码的push操作触发构建,感觉Poll SCM更方便些,如果提交频繁,则这个触发就会频繁,看业务需要设置.
3.Build Environment(设置构建环境)
Delete workspace before build starts:默认删除所有的,也可以设置删除特定的文件
- Patterns for files to be deleted:正则匹配删除哪些文件
- Apply pattern also on directories:规则是否也应用到文件夹
- Check parameter:是否删除,是个bool值,true则删除,false不删除.为毛感觉这个有点鸡肋
- External Deletion Command:执行外部删除命令
Abort the build if it’s stuck:构建阻塞的时候,根据超时策略处理.
- Time-out strategy:超时策略,有绝对时间,相对时间,根据以前的构建时间判断等
- Time-out variable:超时时间
- Time-out actions:超时后的处理,如终结,faile调或者写描述
- Add timestamps to the Console Output:在输出界面添加时间戳
- Use secret text(s) or file:使用密文,用于全局性的管理密码等,勾选后会在下方出现Binding,输入需要的用户名,密码证书等就可以了
4.Build(构建)
这个可以执行多种命令,如window的批处理,shell等一般shell就可以了.平时的自定义编译命令,打包等等,都可以写在这里.jenkins推荐将过长的命令写到下载的源码里,由这个里面的shell命令调用.jenkins执行的时候会默认把所有的命令都打印出来,这样方便调试.可以创建多个build step,这些step是串行的,一个faile,,后面的step都不会执行了.
5.Post-build Actions
可以根据build的结果设置发送邮件,打包,执行其他任务等等.build成功还是失败都会走到这一步.
三.总结
jenkins很强大,目前刚入门.他的作用不仅仅是编译代码,还可以执行其他任意定时任务,监控任务.配合分布式部署,可以实现大规模的协作使用.后面将对jenkins的插件开发和源码结构进行分析.