Gitlab CI Devops
文章目录
上周把只有一个 build_job
的 GitLab CI 重构了一下,简单梳理了一下 GitLab CI 的基本概念。
基本概念
以下面的这张图片为例,能很清楚看出 Pipeline
、Stage
和 Job
三种概念的不同。
Pipeline
一个 Pipeline 为一次构建任务,中文意思为流水线,可以将我们的代码想象为原材料,经过流水线加工后得到最终的产品。
上面这张图表示的就是一个 pipeline 的构建流程,即 Prepare(安装依赖) => Test(测试) => Build(构建) => Deploy(部署)
。整个构建流程通过 .gitlab-ci.yml
中的 stages
定义。
如上图的示例配置如下:
|
|
Stage
一个 Pipeline 包含多个 Stage ,每个 Stage 可以有多个 Job 。Stage 可以理解为加工的工序,多个 Stages 按照定义顺序执行的。如果某个 Stage 运行失败,后续的 Stages 都不会运行。
Job
Job 为最小的运行单元,每个 Job 之间的环境是互相隔离的,同一个 Stage 下的不同 Jobs 可以并行运行。
其中最需要注意的是每个 Job 之间的运行环境是隔离的,即我在 Job1 安装依赖、创建文件,之后运行的 Job 2 是不会受到 Job 1 环境的影响。如果需要在不同 Job 之间共享文件,就需要用到 Cache 或者 Artifacts 。
其他概念
cache
在 Job 小节中说过,每个 Job 的环境是互相隔离的,所以在需要共享某些文件的时候,就需要用到 cache
或者 artifacts
。
cache 一般的应用场景是缓存构建依赖,避免重复安装依赖。例如 npm 的 node_modules
,首次安装依赖时往往需要几分钟,命中 cache 时,只需要几秒钟即可完成安装。
参考文档:
配置说明:
paths
-Array
- 需要缓存的目录、文件key
-String
- 缓存key,通过key
来判断缓存是否命中policy
- 很有用的一个特性,可以配置pull
(仅获取 cache,不更新) /push
(只更新 cache) /pull-push
(default)
运行流程:
恢复 cache (pull)
=>运行 Job script
=>更新 cache (push)
在某些情况下,配置适当的 policy 可以加快 Job 的速度。例如在 test job 可配置为 pull
,即只获取依赖,不更新依赖。
artifacts
不同于 cache,artifacts 偏持久的存储构建结果。主要用途有两个:
- 提供构建结果的下载(例如构建了一个 Jar 包,需要手动下载部署);
- 共享构建 Job 的构建结果。例如在上面例子的中的 deploy stage,就使用了 build stage 的 artifacts。
tags
tags
一般用于控制 Runner 的资源。Job 上定义 tags ,说明这个 Job 将会运行在这个接收这个 Tag 的 Runner 中。
这个用于控制对机器的不同需求或者是按团队分组,例如某个任务需要跑在有 GPU 的机器上,就可将有 GPU 的 Runner 标上
gpu
标签,然后将某个 Job 指定gpu
标签。
Tips
忽略某行脚本的报错:
|
|
测试 schedules:
GitLab Web UI 上配置的 Target Branch
是指它会触发 Target Branch
分支下的 schedules jobs,如果这个分支下不存在 schedules 任务,则不会创建 pipeline。
想手动触发 schedules 进行测试只需要按播放按钮就可以触发一次 schedules 构建事件。
Reference
文章作者 sdvcrx
上次更新 2019-11-01