GitLab CI/CD

当今软件开发行业中，持续集成和持续交付已经成为日常工作中不可或缺的一部分。这是因为在一个团队协作的环境中，每个人都需要不断地将他们的代码与整个代码库进行集成和测试。为了简化这一过程，GitLab CI/CD 工具被越来越多的团队所采用，它可以帮助团队自动化构建、测试和交付他们的软件。本文将介绍 GitLab CI/CD 的基本概念，以及如何使用它来提高团队的工作效率和代码质量。

Job

一个stage可以有若干个 job，各 job 间并行执行，所有 job 成功，整个 stage 才会成功

单个 job 下的 script 执行顺序是串行的。

问：一个job做完所有事情，还是拆分成多个job？

答：如果 script 间没有强逻辑依赖都可以拆分成多个 job；例代码格式化检查，分别校验 js / md / css 文件，让他们同时进行。但是如果为简单的script，就没有必要拆分了，因为每个任务的执行都要经过初始化、拉取缓存等步骤，对于 script 比较简单的 job 来说反而拖慢了整个 job 执行时间，反而不如合并 job

~/.gitlab-runner/config.toml

yaml
concurrent = 2 # 单个stage可以同时并行的job任务数量 default：1

demo

yaml
lint:
  stage: test
  script:
    - npm run lint

# unit test
test:
  stage: test
  script:
    - npm run test

# coverage check
cov:
  stage: test
  script:
    npm run cov

Pipleline

一个Pipleline有若干个stage，每个stage上有至少一个Job，如下图所示

各 stage 间串行执行，即前一个 stage 执行成功后才会执行下一个，所有 stage 成功后，整个任务才会成功

每个阶段执行都会初始化代码，即不保留中间过程产物，如：node_modules，build 等目录

定义stages


stages:
    - install
    - build
    - test

cache、artifacts

cache

设计用于项目依赖，典型的像 node_modules

install 如果有缓存，可以加快执行速度，如果没有则会完整执行命令，增加耗时，但不会执行失败。缓存只是尽力而为之，所以别期望缓存会一直存在

缓存文件存放在Runner机器上，MacOs下：/Users/ccz/cache/chenglin/gitlab-ci-test(用户home目录下>gitlab昵称>绑定的gitlab项目名称)

每个job，都是独立的，会默认把前一个job新增的资源删除得干干静静，也就是说我们前一步 npm install 安装的node_modules资源无法用于下一个job，所以我们需要利用cache去缓存文件

在默认情况下，如果有 cache 的配置，那么每个 job 会在开始执行前将对应路径的文件下载下来，并在任务结束前重新上传，不管文件是否有变化都会如此操作。这个默认的配置是 cache:policy 中的pull-push 策略

yaml
cache: # 缓存
  key: nodeModule  # 缓存默认名称为default。当有新缓存时，新的会覆盖老的。所以当有多份缓存时，需要使用key进行区分
  untracked: true # 缓存所有未被git跟踪的文件
  policy: pull-push # 默认值：pull-push，也可以使用pull or push
  paths:  # 缓存指定文件目录
    - node_modules

artifacts

设计用来跨 stage 共享中间产物，例如 build/ dist/ 等目录

中间产物可以在所有stage中进行使用，使用时，需要定义dependencies属性

中间产物最终可以在GitLab上进行下载

yaml
artifacts:
  name: "$CI_COMMIT_REF_NAME" # 文件名称
  expire_in: 40 sec # 指定过期时间，默认以秒为单位，默认值为30 天
  untracked: true # 保存所有未被git跟踪的文件为中间产物
  paths: # 保存指定文件目录为中间产物
     - build/

Runner

GitLab CI/CD 提供了运行平台的机制，它提供了一个叫gitlab-runner的软件

只要在对应的平台(机器或docker)上下载并运行这个命令行软件，并输入从GitLab交互界面获取的toke，就可以把当前机器和对应的GitLab CI/CD 流程绑定，也即：每次跑 CI/CD 都在这个平台上进行

Shared Runner 是Gitlab平台提供的免费使用的runner程序，它由Google云平台提供支持，每个开发团队有十几个。对于公共开源项目是免费使用的，如果是私人项目则有每月2000分钟的CI时间上限。

Specific Runner是我们自定义的，在自己选择的机器上运行的runner程序，GitLab给我们提供了一个叫gitlab-runner的命令行软件，只要在对应机器上下载安装这个软件，并且运行gitlab-runner register命令，然后输入从 GitLab CI/CD 交互界面获取的token进行注册, 就可以在自己的机器上远程运行pipeline程序了

当我们不填写 tags，会默认跑Shared Runner
Shared Runner 当然也可以不用官方提供的runner程序，可以使用自己的runner程序，这样就没有2000分钟的使用限制了
可以使用Specific Runner tags，这样就会在对应机器上运行对应脚本