GitHub Actions Cache 项目中 save-always 功能的深度解析与技术实践

背景与问题发现

在持续集成/持续部署(CI/CD)流程中，缓存机制是提升构建效率的重要手段。GitHub Actions Cache 作为 GitHub 提供的官方缓存解决方案，其 v4.0 版本中引入的 save-always 功能设计初衷是允许用户在构建步骤失败时仍然保存缓存。然而，多位开发者报告该功能在实际使用中存在异常行为。

问题现象分析

开发者 DanMawdsleyBA 在配置中将 save-always 参数设置为 true，期望即使任务失败也能执行缓存保存步骤。但从实际运行日志可见：

1. 虽然明确设置了 save-always: true
2. 当后续步骤出现失败时
3. 预期的缓存保存步骤并未执行

多位开发者（包括 SukkaW 和 sascha-wolf）也确认遇到了相同问题，证明这不是孤立案例。

技术根源探究

GitHub Actions 核心团队成员 joshmgross 经过深入分析后指出：

1. 当前 GitHub Actions 的 post-if 表达式存在固有技术限制
2. 这些限制导致 save-always 功能无法按预期工作
3. 原始实现（PR #1242）未经充分测试就被合并，存在设计缺陷

官方解决方案

基于技术限制的客观现实，官方提出了替代方案：

推荐做法：使用独立 save/restore 操作

steps:
  - uses: actions/cache/restore@v4
    id: cache-restore
    with:
      path: dependencies
      key: ${{ runner.os }}-deps

  # 构建步骤...

  - uses: actions/cache/save@v4
    if: always() && steps.cache-restore.outputs.cache-hit != 'true'
    with:
      path: dependencies
      key: ${{ steps.cache-restore.outputs.cache-primary-key }}

关键改进点：

1. 将缓存操作拆分为独立的 restore 和 save 步骤
2. 通过 if 条件显式控制 save 步骤的执行逻辑
3. 结合 cache-hit 输出避免不必要的保存操作

版本演进策略

考虑到功能完整性和维护可持续性，官方制定了明确的版本路线：

1. 在当前版本中将 save-always 标记为废弃（deprecated）
2. 更新文档明确推荐替代方案
3. 计划在下一主版本中完全移除 save-always 参数

最佳实践建议

对于需要"失败时仍保存缓存"场景的用户：

1. 立即迁移到独立的 save/restore 操作模式
2. 在 save 步骤中合理设置 if 条件
3. 考虑缓存命中状态避免冗余操作
4. 监控 GitHub Actions 的更新公告

技术启示

这个案例展示了几个重要的工程实践：

1. 功能设计需要考虑平台底层限制
2. 完善的测试覆盖对质量保障至关重要
3. 及时识别不可行方案并制定迁移路径
4. 清晰的文档和示例能有效降低用户迁移成本

通过这个案例，开发者可以更深入地理解 GitHub Actions Cache 的工作原理，并在自己的 CI/CD 流水线中实现更健壮的缓存策略。