如何让GitLab CI同阶段并发运行的runner之间共享缓存

问题根因 #

你的缓存无法跨并发runner调用，本质是GitLab Runner默认使用本地缓存模式时，每个并发worker（即后缀带concurrent-0、concurrent-1的实例）的缓存存储目录相互隔离，缓存仅保存在生成它的worker本地，其他worker无法直接访问。

可行解决方案 #

方案1：调整Runner配置使用共享本地缓存（适合自部署Runner场景） #

直接修改Runner的全局配置，让所有并发worker共用同一个缓存目录：

1. 登录Runner部署服务器，打开配置文件 /etc/gitlab-runner/config.toml
2. 找到对应项目的Runner配置块，修改配置如下（以docker执行器为例）：

[[runners]]
  name = "你的runner名称"
  url = "你的GitLab服务地址"
  token = "对应Runner的token"
  executor = "docker"
  cache_dir = "/data/shared/gitlab-cache" # 所有并发worker共用的缓存目录
  [runners.docker]
    volumes = ["/data/shared/gitlab-cache:/cache"] # 将共享目录挂载到执行容器内

3. 重启Runner生效：gitlab-runner restart

方案2：改用CI制品传递依赖（无需修改Runner配置，临时可用） #

如果没有权限修改Runner配置，可以把第一阶段安装好的node_modules作为临时制品传递给后续任务，替代缓存逻辑：

stages:
  - prepare
  - build_test

# 第一阶段依赖安装任务
install_deps:
  stage: prepare
  script:
    - yarn install --frozen-lockfile
  artifacts:
    paths:
      - node_modules
    expire_in: 1h # 短时效自动清理，避免占用过多存储
  only:
    refs:
      - merge_requests
      - master
    changes:
      - yarn.lock

# 第二阶段并发任务自动拉取制品
build:
  stage: build_test
  script:
    - yarn build

test:
  stage: build_test
  script:
    - yarn test

方案3：使用分布式缓存（企业级场景最优解） #

如果你的GitLab服务已经配置了S3兼容的对象存储作为统一缓存后端，只需调整CI缓存配置的策略，即可让所有并发runner从统一存储拉取缓存：

# 全局缓存配置
cache:
  key:
    files:
      - yarn.lock
  paths:
    - node_modules
  policy: pull # 后续任务默认仅拉取缓存，不修改

# 仅依赖安装任务有权限更新缓存
install_deps:
  stage: prepare
  script:
    - yarn install --frozen-lockfile
  cache:
    inherit: true
    policy: pull-push
  only:
    refs:
      - merge_requests
      - master
    changes:
      - yarn.lock

内容的提问来源于stack exchange，提问作者dragonfly