GitLab CI/CD 的执行流程

介绍

GitLab CI/CD 是一个简洁好用的的持续集成/持续交付的框架。通过为你的项目配置一个或者多个 GitLab Runner,然后撰写一个 .gitlab-ci.yml,你就可以很方便地利用 GitLab CI/CD 来为你的项目引入持续集成/交付的功能。

执行流程

Stage

GitLab CI/CD 的执行过程中首先驱动的是 Stage。

CI 中 Stage 的执行

每个 GitLab CI/CD 都必须包含至少一个 Stage。多个 Stage 是按照顺序执行的。如果其中任何一个 Stage 失败,则后续的 Stage 不会被执行,整个 CI 过程被认为失败。

以图中所示为例,整个 CI 环节包含三个 Stage:buildtest
deploy

  • build 被首先执行。如果发生错误,本次 CI 立刻失败;
  • testbuild 成功执行完毕后执行。如果发生错误,本次 CI 立刻失败;
  • deploytest 成功执行完毕后执行。如果发生错误,本次 CI 失败。

Stage 在 .gitlab-ci.yml 中通过如下的方式定义:

stages:
  - build
  - test
  - deploy

如果文件中没有定义 stages,那么则默认包含 buildtestdeploy 三个 stage。

Stage 中并不能直接配置任何具体的执行逻辑,具体的执行逻辑应该在 Job 中配置。

Job

Stage 中 Job 的执行

Job 可以被关联到一个 Stage。当一个 Stage 执行的时候,与其关联的所有 Job 都会被执行。需要注意的是,Job 在设计上是可并行执行的。这样的好处是可以利用多个 Runner 来加速 CI/CD 的流程。

因此,如果 Job 之间有依赖关系的话,需要通过关联到不同的 Stage 来实现。

Job 在 .gitlab-ci.yml 中通过如下的方式来和 Stage 关联:

job_build_module_A:
  stage: build

如果一个 Job 没有显式地关联某个 Stage,则会被默认关联到 test Stage。

Job 的执行

Job 包含了真正的执行逻辑,例如调用 mvn 或者 gcc 等命令。

job_build_module_A:
  script:
    - cd module_A
    - mvn clean compile

公共配置

随着项目越来越大,Job 越来越多,Job 中包含的重复逻辑可能会让配置文件臃肿不堪。.gitlab-ci.yml 中提供了 before_scriptafter_script 两个全局配置项。这两个配置项在所有 Job 的 script 执行前和执行后调用。

例如:

job_build_module_A:
  script:
    - export MAVEN_OPTS="-Xmx256m"
    - cd module_A
    - mvn clean compile

...

job_build_module_Z:
  script:
    - export MAVEN_OPTS="-Xmx256m"
    - cd module_Z
    - mvn clean compile

这其中 export MAVEN_OPTS="-Xmx256m" 显然是可以抽取公用的部分,在 before_script 的帮助下,配置文件可以优化成:

before_script:
  - export MAVEN_OPTS="-Xmx256m"

job_build_module_A:
  script:
    - cd module_A
    - mvn clean compile

...

job_build_module_Z:
  script:
    - cd module_Z
    - mvn clean compile

after_script 也可以起到类似的作用,不过是在每个 Job 执行完毕以后被调用。

公共数据 - Cache

Job 的执行过程中往往会产生一些数据,默认情况下 GitLab Runner 会保存 Job 生成的这些数据,然后在下一个 Job 执行之前(甚至不局限于当次 CI/CD)将这些数据恢复。这样即便是不同的 Job 运行在不同的 Runner 上,它也能看到彼此生成的数据。

不过这些行为可能会带来意料之外的问题,比如说上一次 CI/CD 执行的是 master 分支的 build,下一次 CI/CD 执行的却是 devel 分支的 build,而 build 脚本偏偏是增量执行的,那么有可能导致第二次 build 的过程错误地引用了 master 编译生成的中间结果。

这个情况下,我们需要配置 cache.key

cache:
  key: "$CI_COMMIT_REF_NAME"

这个配置的意思是:所有的 Job 在恢复 cache 的时候,是根据当前的分支名称去选择对应的 cache。换句话说,前面例子中的两次 build 会选中不同的 cache,数据自然就隔离开了。

当然,上面的隔离粒度是分支级别的,你还可以配置成 分支+Job 级别的:

cache:
  key: "$CI_JOB_NAME-$CI_COMMIT_REF_NAME"

上面两个例子中的 CI_COMMIT_REF_NAMECI_JOB_NAME 是 GitLab CI/CD 的预定义变量。除了它们以外,还有许多预定义变量可以供我们选择,详情可以参阅《GitLab CI/CD Variables: Predefined variables》

Job 的执行总览

在了解了 Job 配置的 scriptbefore_scriptafter_scriptcache 以后,我们便可以将整个 Job 的执行流程用一张图概括下来了:

Job 执行流程

总结

通过上面的介绍,我们可以了解到:

  1. GitLab CI/CD 是通过 GitLab Runner 来执行的
  2. GitLab CI/CD 将按照 Stage 定义的顺序来执行,任何一个 Stage 失败,整个 CI/CD 将失败
  3. 每一个 Stage 可以被若干个 Job 关联。Stage 在执行的时候,关联到这个 Stage 的所有 Job 都将被执行,不过不同的 Job 可能是并行执行的。
  4. 每个 Job 在执行的时候,会先按照缓存策略加载缓存数据,然后按照顺序依次运行 before_scriptscriptafter_script 中配置的脚本,运行完毕以后,会将生成的数据保存到缓存中。

参阅

推荐阅读更多精彩内容