GitLab CI 能做什么
比如,
- 项目的单元测试覆盖率检查
- 项目中每次合并到
master
分支时都生成一个tag
使用
必备条件: 有一个8.0+版本的
Gitlab
, 或者使用gitlab.com
,gitlab.com
有免费的共享Runner
- 在项目中的根目录添加
.gitlab-ci.yml
文件 - 配置
GitLab Runner
概念
几个关键的概念
.gitlab-ci.yml
几乎所有的工作都是在 .gitlab-ci.yml
文件中做的, .gitlab-ci.yml
文件定义了GitLab CI
要对项目的事情, 比如跑单元测试/自动构建/发布…
每次有代码 push
到仓库, GitLab Runner
都会去检查 .gitlab-ci.yml
文件, 然后开始执行 .gitlab-ci.yml
文件中的定义 jobs
.
一个简单的.gitlab-ci.yml
1 | before_script: |
jobs
具体的构建工作
.gitlab-ci.yml
中可以定义无数个jobs
:
1 | run_test: |
jobs 中的关键词
有很多关键词, 将近20个: script
stage
type
variables
等等, 简单介绍几个:
- script: 是由
Runner
执行的shell
脚本 - stage: 将
jobs
分成不同阶段, 相同阶段的jobs
以并行的方式执行 - only and except: 限制
jobs
什么时候执行 如:pushes
branches
tags
等等 - Job variables: 自定义的
job
变量
stages
定义了 jobs
中执行的阶段, 阶段的名字可以自定义, stages
中阶段定义的顺序就是 jobs
的执行顺序
如果没有定义 stages
结点, 则只能在 jobs
中使用 build
test
deploy
三个阶段, 而 stages
中的阶段名名称可以自定义:
1 | # test1 和 test2 会先于 build 执行 |
pipline
pipline
可以简单的理解为一次构建, 一次构建中可以包含 test
build
production
等阶段.
它是一组按 stages
执行的 jobs
, 同一个阶段(stage
)的 jobs
都是按照并发执行的方式进行的, 一般情况下, 只有当前阶段的所有jobs
都成功执行了,pipline
才能进行下一个阶段的执行,如果有一个失败了,后续阶段的 jobs
都不会执行.
图示
更多
- 安装配置
Gitlab Runner
- 文档
- .gitlab-ci.yml Reference
- 用 lint 校验
yml
语法, 可以节省时间 - GitLab CI/CD Variables