Ci Build Cache Advisor — CI 构建缓存顾问

CI 构建缓存顾问 优化 GitHub Actions、GitLab CI、CircleCI 和 Jenkins 的 CI/CD 构建缓存策略。分析缓存配置，推荐缓存键，识别缓存失误，并通过最大化缓存命中率来减少构建时间。 用法 “优化我的 CI 流水线缓存” “为什么我的构建不使用缓存？” “为我的 monorepo CI 设计缓存键” “减少我的 CI 构建时间” 工作原理

• CI 平台检测

ls .github/workflows/ 2>/dev/null && echo "GitHub Actions" ls .gitlab-ci.yml 2>/dev/null && echo "GitLab CI" ls .circleci/config.yml 2>/dev/null && echo "CircleCI" ls Jenkinsfile 2>/dev/null && echo "Jenkins"

• 缓存分析

应该缓存的内容： 包管理器依赖项（node_modules、.pip、.cargo、.gradle） 构建工件（编译代码、生成资产） Docker 层 测试固定装置和快照 Linter 和类型检查器缓存 缓存键策略： 主键：锁文件哈希（package-lock.json、Cargo.lock） 恢复键：平台 + 分支回退 矩阵感知：每个 OS/Node 版本/Python 版本的不同缓存 monorepo：工作区特定的缓存

• 常见问题

缓存太宽：整个 node_modules 的单个缓存被任何依赖项更改失效 缓存太窄：缓存键包含提交 SHA（永远不会命中） 缺少恢复键：没有回退时主键失误 缓存污染：开发依赖项被缓存用于生产构建 过时缓存：缓存永远不会过期，使用过时的工件 缓存大小限制：超过平台限制（GitHub：10GB，GitLab：各不相同）

• 各平台的推荐

GitHub Actions：

• uses: actions/cache@v4

with: path: ~/.npm key: ${{ runner.os }}-npm-${{ hashFiles('/package-lock.json') }} restore-keys: | ${{ runner.os }}-npm- GitLab CI： cache: key: files: - package-lock.json prefix: $CI_JOB_NAME paths: - node_modules/ policy: pull-push

• 高级策略

Turbo/Nx 远程缓存：在 CI 和开发人员之间共享构建缓存 Docker 层缓存：BuildKit 缓存挂载、注册表支持缓存 Gradle 构建缓存：团队范围内的远程缓存服务器 ccache/sccache：C/C++/Rust 编译缓存 输出

CI 缓存优化

平台： GitHub Actions | 工作流： 3

当前缓存使用情况

| 工作流 | 缓存配置 | 命中率 | 构建时间 | |----------|-----------------|----------|------------| | CI | 是（npm） | 67% | 8m 30s | | Deploy | 否 | 0% | 12m 15s | | Release | 部分 | 45% | 15m |

推荐

• 将 npm 缓存添加到 Deploy 工作流 —— 每次运行节省 ~3 分钟
• 修复 CI 缓存键 —— 包括分支名称（PR 上的命中率低）→ 删除分支，仅使用锁文件哈希
• 将 Docker 层缓存添加到 Release —— 每次运行节省 ~5 分钟
• 添加 TypeScript 构建缓存** —— tsBuildInfoFile 未缓存

预计改进

• CI：8m 30s → 3m 45s（56% 更快）
• Deploy：12m 15s → 7m（43% 更快）
• Release：15m → 8m（47% 更快）
• 每月节省的分钟数：~2,400（~$19）