GitLab CI 持续集成

GitLab CI 能做什么

比如,

• 项目的单元测试覆盖率检查
• 项目中每次合并到 master 分支时都生成一个 tag

使用

必备条件: 有一个8.0+版本的 Gitlab, 或者使用 gitlab.com, gitlab.com 有免费的共享 Runner

1. 在项目中的根目录添加.gitlab-ci.yml文件
2. 配置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

before_script:
  - echo build started

# jobs
run_test:
  stage: test
  script:
    - npm run test:coverage
  only:
    - branches
    - pushes
  coverage: '/Branches.*?(\d+(?:\.\d+)?)%/' # 测试覆盖率收集

stages:
  - test
  - release

jobs

具体的构建工作

.gitlab-ci.yml中可以定义无数个jobs:

run_test:
  stage: test
  variables:
    REQUIRED_COVERAGE: 10
  script:
    - echo "test stage"
  only:
    - branches
    - pushes
  coverage: '/Branches.*?(\d+(?:\.\d+)?)%/'

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 中的阶段名名称可以自定义:

# test1 和 test2 会先于 build 执行
stages:
  - 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