在某一些事件下可以自动触发脚本(比如代码提交， 代码合并，定时出发)帮我们构建我们的项目， 比如提交代码到git, 自动跑我们预先定义的脚本，完成单元测试
+------------------+ +----------------+
| | trigger | |
| Commit / MR +---------->+ Pipeline |
| | | |
+------------------+ +----------------+
一句话理解： 自动帮我们跑一段脚本
已经正确从gitlab中获取到runner
在项目「根目录」， 维护.gitlab-ci.yml, 定义如何执行响应脚本
关键点： 部署在项目根目录， 定义构建流程。
测试环境需要 根据我们编写的.gitlab-ci.yml文件内容， 来正确执行构建， 我们需要理解一些基本语法概念
预先定义会经历多少个「阶段」， 比如基本的软件阶段是 {编码} ----> {测试} ---->{部署}， 三个阶段是串行， 只有 编码成功， 才能进入测试阶段， 只有测试成功， 才能进入部署阶段， 前一个阶段失败， 影响进入下阶段
如果没有定义stage, 默认有{build}{test}{deploy}阶段
但是在某个阶段中的job是并行进行，互不影响， 如果一个job失败， 不影响其他job正常进行
job中需要标注该job属于哪个阶段
job01:
stage: build ------->这里需要指定job01是哪个阶段， 默认是test阶段
script:
- echo "hello world"
+--------------------------------------------------------+
| |
| Pipeline |
| |
| +-----------+ +------------+ +------------+ |
| | Stage 1 |---->| Stage 2 |----->| Stage 3 | |
| +-----------+ +------------+ +------------+ |
| |
+--------------------------------------------------------+
runner执行的基本单元， 类比是一个函数方法
比如：
job1: script: "execute-script-for-job1"
job2: script: "bash test.sh"
job必须有唯一的名字， 不能重复
比如我们如下定义
litong_job: --------job名字
script: ----------需要执行的脚本
- uname -a ---------具体要执行的脚本内容
- echo "hello world" --------具体要执行的脚本内容
+------------------------------------------+
| |
| Stage 1 |
| |
| +---------+ +---------+ +---------+ |-----> stage 2
| | Job 1 | | Job 2 | | Job 3 | |
| +---------+ +---------+ +---------+ |
| |
+------------------------------------------+
集成模版， 我们可以定义模版job， 然后具体的job可以集成自模版job
在script 处理前 需要 执行的钩子脚本
在script 处理之后需要执行的勾子脚本
如果， 是全局的before_script, 和after_script, 则应用于每个script
是必须存在的关键字， 需要执行的脚本内容 比如
only和except用来限制需要执行该任务的分支。这个指令非常重要，特别是对于部署任务，例如develop分支部署到测试环境，master部署到生产环境。也可以使用通配符。
默认是 [branches, tags] 作业指定是对所有分支， 所有tags进行
比如： 我们可以指定持续集成 只针对develop和release分支
only: - <一个匹配tag名字的正则>
when用于指定执行该任务的条件。非常有用，例如部署生产环境，采用manual更为稳妥。
选择指定的 runner运行