GitLab学习
创建自己的账号： https://jihulab.com/
自己学习建议选：SaaS 免安装
一、Gitlab CI 是什么？
现代持续的软件开发导致了开发者需要持续的build, test 和 deploy 重复的代码更改，这些重复的过程非常的繁琐，但是对保证代码持续更新迭代来说又非常的重要。此时便需要一种非人为手动的方法来帮助我们自动完成这些重复的工作。
这个自动完成工作的理念被称为CI/CD. 在这里Gitlab CI/CD就是Gitlab官方发布的一种自动流水线帮助开发者完成重复性工作的一个服务。
二、GitRunner
gitrunner是什么？
是gitlab的持续集成服务，他会与gitlab通讯能够在runner与gitlab之间共享代码， 当gitlab收到一个动作（钩子），会通知runner作出相应动作
GitLab Runner的三种类型
- shared：运行整个平台项目的作业(gitlab)
- group：运行特定group下的所有项目的作业(group)
- specific：运行指定的项目作业(project)
GitLab Runner两种状态
- locked：无法运行项目作业
- paused：不会运行作业
GitLab Runner安装
三、流水线（ pipelines）
pipelines包括：
- 工作（Jobs），定义做什么。例如，编译或测试代码的作业。
- 阶段（Stages），定义何时运行作业。例如，在编译代码的阶段之后运行测试的阶段。
作业由 runners 执行。如果有足够多的并发运行程序，同一阶段的多个作业将并行执行。
如果一个阶段中的所有作业成功，流水线将进入下一个阶段。
如果某个阶段中的任何作业失败，则下一个阶段（通常）不会执行并且流水线提前结束。
一般来说，流水线是自动执行的，一旦创建就不需要干预。但是，有时您也可以手动与流水线交互。
一个典型的流水线可能包含四个阶段，按以下顺序执行：
- 一个 build 阶段，有一个名为 compile 的作业。
- 一个 test 阶段，有两个名为 test1 和 test2 的作业。
- 一个 staging 阶段，有一个名为 deploy-to-stage 的作业。
- 一个production阶段，有一个名为deploy-to-prod的作业。
pipelines 类型
流水线可以通过多种不同的方式进行配置：
- 基本流水线：同时运行每个阶段的所有内容，然后是下一个阶段。
- 有向无环图 (DAG) 流水线：基于作业之间的关系，可以比基本流水线运行得更快。
- 多项目流水线：将不同项目的流水线组合在一起。
- 父子流水线：将复杂的流水线分解为一个可以触发多个子流水线的父流水线，这些子流水线都运行在同一个项目中并具有相同的 SHA。这种流水线架构通常用于 mono-repos。
- 合并请求的流水线：仅针对合并请求运行（而不是针对每次提交）。
- 合并结果的流水线：是来自源分支的更改已经合并到目标分支的合并请求流水线。
- 合并队列：使用合并结果流水线将合并一个接一个地排队
配置pipelines
流水线及其组件作业和阶段在每个项目的 CI/CD 流水线配置文件中定义。
查看pipelines
您可以在项目的 CI/CD > 流水线 页面下找到当前和历史流水线运行。您还可以通过导航到其 流水线 选项卡来访问合并请求的流水线。
stages
Gitlab CI允许我们进行自定义的流水线阶段配置，我们可以将自己的流水线自我划分为若干stages，然后在不同的stage来做不同的事。
stages会依次执行，如果前一个stage的任务没有运行完，后面的stage不会被触发。
一旦有一个stage中的任务fail掉了，下一个stage的任务便不会执行。如果当前stage定义了多个任务，那么其中一个任务失败，另外一个任务还是会被继续执行。
pipelines 配置参考：
中文： https://docs.gitlab.cn/jh/ci/yaml/index.html
英文： https://docs.gitlab.com/ee/ci/yaml/index.html
pipelines详情： https://docs.gitlab.cn/jh/ci/pipelines/
四、作业（Jobs）
流水线配置从作业开始。作业是 .gitlab-ci.yml 文件中最基本的元素。
工作是：
- 定义了约束条件，说明它们应该在什么条件下执行。
- 具有任意名称的顶级元素，并且必须至少包含 script 子句。
- 不限制可以定义的数量。
例如：
job1:
script: "npm run install "
job2:
script: "npm run test"上面的示例是最简单的 CI/CD 配置，具有两个单独的作业，其中每个作业执行不同的命令。 当然，命令可以直接执行代码（./configure;make;make install）或在仓库中运行脚本（test.sh）。
作业由 runners 拾取并在 runner 的环境中执行。重要的是，每个作业都是相互独立运行的。
作业状态的顺序是：
- failed
- warning
- pending
- running
- manual
- scheduled
- canceled
- success
- skipped
- created
流水线中分组作业
如果您有许多类似的作业，您的流水线图会变得很长且难以阅读。
您可以自动将相似的作业组合在一起。如果作业名称以某种方式格式化，它们将在常规流水线图（而不是迷你图）中折叠成一个组。
如果您没有在其中看到重试或取消按钮，您可以识别流水线何时对作业进行了分组。将鼠标悬停在它们上会显示分组作业的数量，单击可以展开它们。
要创建一组作业，请在 CI/CD 流水线配置文件中，将每个作业名称用数字和以下之一分隔：
- 斜线（/），例如 slash-test 1/3、slash-test 2/3、slash-test 3/3。
- 冒号 (😃，例如 colon-test 1:3、colon-test 2:3、colon-test 3:3。
- 一个空格，例如 space-test 0 3、space-test 1 3、space-test 2 3。
您可以互换使用这些符号。
在下面的示例中，这三个作业位于名为 build ruby 的组中：
流水线图显示了一个名为 build ruby 的组，其中包含三个作业。
通过从左到右比较数字来对作业进行排序。您通常希望第一个数字是索引，第二个数字是总数。
此正则表达式 评估作业名称：([\b\s:] +(([.])|(\d+[\s:/\]+\d+)))+\s\z。 一个或多个: [...]、X Y、X/Y 或X\Y 序列仅从作业名称的结尾中删除。在作业名称的开头或中间找到的匹配子字符串不会被删除。
详细文档
Jobs 详细文档：
https://docs.gitlab.cn/jh/ci/jobs/
https://docs.gitlab.com/ee/ci/jobs/
五、变量（variables）
CI/CD 变量是一种环境变量。 您可以将它们用于：
- 控制作业和流水线。
- 存储要重复使用的值。
- 避免在您的 .gitlab-ci.yml 文件中硬编码值。
您可以使用预定义 CI/CD 变量或自定义：
您可以为特定流水线手动覆盖变量值，或让它们在手动流水线中预填入。
变量名称受限于 runner 使用的 shell 来执行脚本。每个 shell 都有自己的一组保留变量名。
确保每个变量都是为您要使用它的范围定义的。
在 .gitlab-ci.yml 文件中定义 CI/CD 变量
要在 .gitlab-ci.yml 文件中创建自定义变量，请使用 variables 关键字定义变量和值。
您可以在作业中或在 .gitlab-ci.yml 文件的顶层使用 variables 关键字。 如果变量在顶层，则它是全局可用的，所有作业都可以使用它。 如果它在作业中定义，则只有该作业可以使用它。
保存在 .gitlab-ci.yml 文件中的变量应该只存储非敏感的项目配置，比如 RAILS_ENV 或 DATABASE_URL 变量。这些变量在仓库中可见。 在项目设置中存储包含例如 secret、密钥等值的敏感变量。
.gitlab-ci.yml 文件中保存的变量也可以在 service 容器中使用。
如果您不想在作业中使用全局定义的变量，请将 variables 设置为 {}：
使用 value 和 description 关键字来定义用于手动触发的流水线的预填充的变量。
详细文档
https://docs.gitlab.cn/jh/ci/variables/
六、 缓存和产物
缓存是作业下载和保存的一个或多个文件。使用相同缓存的后续作业不必再次下载文件，因此它们执行得更快。
要了解如何在您的 .gitlab-ci.yml 文件中定义缓存
缓存： https://docs.gitlab.cn/jh/ci/yaml/index.html#cache
缓存与产物的不同之处
对依赖项使用缓存，例如您从 Internet 下载的包。 如果启用分布式缓存，则缓存存储在安装了 GitLab Runner 并上传到 S3 的位置。
使用产物在阶段之间传递中间构建结果。 产物由作业生成，存储在系统中，可以下载。
产物和缓存都定义了它们相对于项目目录的路径，并且不能链接到它之外的文件。
缓存
- 使用 cache 关键字定义每个作业的缓存。否则它被禁用。
- 后续流水线可以使用缓存。
- 如果依赖项相同，同一流水线中的后续作业可以使用缓存。
- 不同的项目不能共享缓存。
产物
- 定义每个作业的产物。
- 同一流水线后期的后续作业可以使用产物。
- 不同的项目不能共享产物。
- 默认情况下，产物会在 30 天后过期。您可以自定义到期时间。
- 如果启用了保留最新产物，则最新的产物不会过期。
- 使用依赖来控制哪些作业获取工件。
详细文档：
https://docs.gitlab.cn/jh/ci/caching/
七、其他
image CI流水线运行环境
CI流水线运行环境的docker镜像(任何相关的代码运行环境镜像皆可)
only & except
- nly: 设置流水线任务执行时机
- except: 设置流水线任务不执行时机
可配置选项（常用的几个）：
| <分支名> | 特定分支change的时候触发 |
|---|---|
| pushes | git push时触发，适用于所有分支 |
| merge_requests | MR被创建时触发，适用于所有分支 |
| web | 手动在Gitlab Runner/pipeline里面点击run pipeline时触发 |
配置branch名称来规定触发任务的分支(如下)，
rules:if
此字段可以在单个流水线job或者workflow字段下进行配置。
rules关键词下可以进行if语句配置，如果if满足的话可执行某些自定义配置(会在流水线任务demo2中和workflow配置中展示如何使用)
注意: only & except和rules:if都是用来决定单个job执行时机的，在配置时只能存在一个，否则会报错。
workflow
需要和rules配合用来控制整个pipeline的行为，比如整个流水线执行与否。整个流水线正常运行的前提是其rules配置中的if语句至少需要触发一个.
在各个流水线任务的外层进行配置
when
这个关键字和stage需要配合使用。如果一个stage fail掉了，那么我们应该期待下个stage怎么办呢？
(When to run a job?)
- on_success(default): 所有之前stage的任务都执行成功了才执行当前stage的任务，或者之前fail的任务有配置了allow_failure: true
- on_failure ：只有在之前的流水线任务有至少一次的fail之下才执行当前任务。
- always：无论之前的stage的流水线的任务状态如何，当前的任务都会触发。
- never：不运行当前任务
- manual：流水线手动触发,点击play，如下图
模块化写法
在.gitlab.yml文件中按照如下写法即可引入不同的yml文件
八、如何编写.gitlab-ci.yml文件
YAML语法
数组写法：
转化为yaml为
对象写法：
转化为yaml为
- yaml中不像json那样无法注释，我们可以用#进行注释
简单的CI案例
分析
创建三个 stages
- Build
- Test
- deploy
添加相应的任务 及 script
如下图所示：分为build 、test 、deploy 三个主流程
- 一个stage可以对应多个作业
流水线基础用法
参考文献：