GitLab CI/CD 的执行流程

小灰灰 2021-12-10 04:02 230阅读 0赞

# 介绍 #

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

# 执行流程 #

## Stage ##

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

![Image 1][]

CI 中 Stage 的执行

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

以图中所示为例，整个 CI 环节包含三个 Stage：`build`、`test` 和  
`deploy`。

*  `build` 被首先执行。如果发生错误，本次 CI 立刻失败；
 *  `test` 在 `build` 成功执行完毕后执行。如果发生错误，本次 CI 立刻失败；
 *  `deploy` 在 `test` 成功执行完毕后执行。如果发生错误，本次 CI 失败。

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

stages:
      - build
      - test
      - deploy

如果文件中没有定义 `stages`，那么则默认包含 `build`、`test` 和 `deploy` 三个 stage。

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

## Job ##

![Image 1][]

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_script` 和 `after_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_NAME`、`CI_JOB_NAME` 是 GitLab CI/CD 的预定义变量。除了它们以外，还有许多预定义变量可以供我们选择，详情可以参阅[《GitLab CI/CD Variables: Predefined variables》][GitLab CI_CD Variables_ Predefined variables]

## Job 的执行总览 ##

在了解了 Job 配置的 `script`、`before_script`、`after_script` 和 `cache` 以后，我们便可以将整个 Job 的执行流程用一张图概括下来了：

![Image 1][]

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_script`、`script` 和 `after_script` 中配置的脚本，运行完毕以后，会将生成的数据保存到缓存中。

# 参阅 #

*  [GitLab Continuous Integration (GitLab CI/CD)][GitLab Continuous Integration _GitLab CI_CD]
 *  [GitLab: Configuration of your jobs with .gitlab-ci.yml][GitLab_ Configuration of your jobs with .gitlab-ci.yml]

作者：vivimice  
链接：https://www.jianshu.com/p/306cf4c6789a  
来源：简书  
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

[GitLab CI_CD]: https://link.jianshu.com?t=https%3A%2F%2Fabout.gitlab.com%2Ffeatures%2Fgitlab-ci-cd%2F
[Image 1]: 
[GitLab CI_CD Variables_ Predefined variables]: https://link.jianshu.com?t=https%3A%2F%2Fdocs.gitlab.com%2Fce%2Fci%2Fvariables%2FREADME.html%23predefined-variables-environment-variables
[GitLab Continuous Integration _GitLab CI_CD]: https://link.jianshu.com?t=https%3A%2F%2Fdocs.gitlab.com%2Fce%2Fci%2FREADME.html
[GitLab_ Configuration of your jobs with .gitlab-ci.yml]: https://link.jianshu.com?t=https%3A%2F%2Fdocs.gitlab.com%2Fce%2Fci%2Fyaml%2FREADME.html%23configuration-of-your-jobs-with-gitlab-ci-yml