GitLab CI多缓存配置失效问题及正确用法咨询

问题原因分析 #

你遇到的是GitLab CI多缓存的正常行为：每个缓存条目完全独立，对应单独的缓存归档文件，不存在“追加”缓存内容的逻辑。具体来说：

• job b中的第一个缓存项配置了policy: pull-push，仅会在job结束后推送自身指定的paths: - b/，生成对应key的缓存归档（仅包含b/）。
• 第二个缓存项是policy: pull，仅拉取job a生成的a/缓存，但不会在job结束后重新推送a/的内容——a/缓存的维护责任本就属于job a，无需job b重复推送。

所以job b结束后只有b/的缓存被更新，a/的缓存仍为job a生成的版本，这是符合预期的，并非配置错误。你的误解在于认为多缓存的push操作会合并不同key的缓存内容，但实际上每个key的缓存都是独立维护的。

针对你的示例场景的正确配置 #

你的现有配置可以正常工作，只需确保：

1. job a成功执行并推送了a/的缓存
2. job b成功拉取a/的缓存并生成b/的缓存
3. job c拉取两个缓存后，即可获取a/和b/的内容

若需验证，可在job c的script中添加ls -la a/ b/确认目录存在。

实际场景（vendor/与node_modules/）的最优配置 #

针对你提到的composervendor/和yarnnode_modules/缓存需求，推荐独立缓存key+按需拉取的方案，既能保证缓存精准性，又能节省拉取时间：

配置示例 #

# 单独维护composer vendor缓存的job
composer_setup:
  cache:
    key:
      files:
        - composer.lock  # 依赖文件变化时自动更新缓存
    paths:
      - vendor/
    policy: pull-push
  script:
    - composer install --no-dev --optimize-autoloader

# 单独维护yarn node_modules缓存的job
yarn_setup:
  cache:
    key:
      files:
        - yarn.lock  # 依赖文件变化时自动更新缓存
    paths:
      - node_modules/
    policy: pull-push
  script:
    - yarn install --frozen-lockfile

# 需要同时使用两个依赖目录的构建job
app_build:
  needs: [composer_setup, yarn_setup]
  cache:
    - key:
        files:
          - composer.lock
      paths:
        - vendor/
      policy: pull  # 只拉取，无需推送
    - key:
        files:
          - yarn.lock
      paths:
        - node_modules/
      policy: pull
  script:
    - # 执行你的构建命令，如php artisan build 或 yarn build

配置说明 #

• 每个依赖目录对应独立的缓存key，基于各自的锁文件（composer.lock/yarn.lock），仅当依赖版本变化时才生成新缓存，避免无效缓存。
• 依赖安装job负责推送对应缓存，业务job仅拉取所需缓存，减少不必要的推送操作。
• 若有job需同时安装两种依赖，可配置多缓存的pull-push，分别推送各自路径：

install_all_deps:
  cache:
    - key:
        files:
          - composer.lock
      paths:
        - vendor/
      policy: pull-push
    - key:
        files:
          - yarn.lock
      paths:
        - node_modules/
      policy: pull-push
  script:
    - composer install --no-dev
    - yarn install --frozen-lockfile

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