policy: pull 通过只拉不推、精准控制缓存上传时机、避免污染、配合分布式后端与细粒度键设计，提升跨节点流水线依赖复用效率；适用于读多写少且需环境隔离的场景，如mr流水线或并行测试作业。
用 policy: pull 能显著提升跨节点流水线中依赖包的复用效率，但关键不在“只拉不推”，而在于**精准控制缓存上传时机、避免污染、配合分布式后端与细粒度键设计**。它适合那些“读多写少”、且需严格隔离构建环境的场景，比如 MR 流水线或并行测试作业。
明确 policy: pull 的适用定位
该策略表示：作业启动时尝试下载已有缓存，但执行完毕后不更新缓存内容。这意味着：
- 缓存来源必须由其他使用
pull-push或push的作业预先生成（如install_deps） - 多个节点可同时安全拉取同一份缓存，无写冲突风险
- 杜绝了因某次失败构建意外覆盖有效缓存的问题
搭配分布式缓存后端是前提
单机 Runner 的本地缓存对跨节点无效。必须配置共享存储后端，例如 S3、GCS 或 MinIO：
/etc/gitlab-runner/config.toml
[runners.cache.s3] ServerAddress = "your-minio.example.com:9000" AccessKey = "xxx" SecretKey = "yyy" BucketName = "gitlab-runner-cache" Insecure = true
只有在此基础上，policy: pull 才能真正从统一池中拉取，否则各节点仍各自维护本地副本，无法共享。
GitHub Actions Runtime Regression Audit
下载
对比基线与当前 GitHub Actions 运行导出，在 CI 成本和交付周期激增前及时发现工作流或作业运行时性能退化。
按作业职责分离缓存行为
不要让所有作业都用 pull —— 需要分层协作：
-
安装作业（只推）：专责下载和固化依赖，用
policy: push，确保缓存权威性 -
构建/测试作业（只拉）：大量并发运行，全部设为
policy: pull，零写开销，快速就位 -
清理作业（可选）：定期触发
cache: policy: pull-push+ 清理脚本，做缓存健康检查
示例片段：
install_deps:
stage: setup
script: npm ci
cache:
key: ${CI_COMMIT_REF_SLUG}
paths: [node_modules/]
policy: push # 仅此作业更新缓存
<p>unit_test:
stage: test
script: npm run test
cache:
key: ${CI_COMMIT_REF_SLUG}
paths: [node_modules/]
policy: pull # 多个 test job 同时拉取，互不干扰
</p>
缓存键必须稳定且有区分度
若键值频繁变动，pull 就永远找不到可用缓存。推荐组合方式：
-
分支级基础缓存：
key: ${CI_COMMIT_REF_SLUG}—— 主干/特性分支各自独立 -
依赖锁定文件驱动：
key: files: [package-lock.json]—— 内容变才换缓存，精准保鲜 -
混合模式（推荐）：
key: files: [package-lock.json] prefix: ${CI_COMMIT_REF_SLUG}—— 既保分支隔离，又防误复用
注意：MR 流水线默认使用 CI_MERGE_REQUEST_SOURCE_BRANCH_NAME 作为 ref，若需复用目标分支缓存，需显式覆盖 key。
