Haskell Cabal 项目面临 GitHub 缓存限制的挑战

近期 Haskell 生态系统中重要的构建工具 Cabal 在持续集成(CI)流程中遇到了一个棘手的技术问题。GitHub Actions 突然大幅降低了缓存配额，从原先允许的 300GB 骤降至仅 25GB。这一变更对项目的自动化测试流程产生了显著影响。

在 CI 流程中，Cabal 项目原本依赖 GitHub 的缓存机制来存储构建过程中产生的中间文件，特别是用于存储 cabal 可执行文件的缓存。这种设计可以显著加快后续构建的速度，因为系统不需要每次都从头开始编译和下载依赖。然而，新的缓存限制使得这一优化策略难以继续。

技术团队发现，缓存体积过大的主要原因是包含了完整的 cabal 存储库(store)。这些存储数据虽然对本地开发很有价值，但在 CI 环境中可能并非必需。为此，开发者提出了两个潜在的解决方案：

1. 从缓存中移除 cabal 存储库，仅保留最关键的构建产物，试图将总体缓存体积压缩到 GitHub 新的限制范围内
2. 完全放弃使用缓存机制，转而使用 GitHub 的 artifacts(制品)功能来传递构建产物

值得注意的是，项目中名为 "dogfooding" 的测试任务虽然理论上可以利用缓存，但实际上已经采用了 artifacts 方案。这表明团队在缓存策略上已经有所考量，当前的问题主要集中在 CI 流程的其他部分。

对于依赖 Haskell 生态系统的开发者而言，这一事件提醒我们：在设计和优化 CI/CD 流程时，需要考虑到第三方平台可能随时变更其服务条款和资源限制。建立不过度依赖特定平台特性的健壮构建系统，是保证项目持续交付能力的关键。

Cabal 团队正在积极调整他们的 CI 配置，预计将通过精简缓存内容或完全转向 artifacts 的方式来解决这一问题。这一经验也为其他开源项目提供了有价值的参考：在云服务资源日益受限的今天，优化构建系统的资源使用效率变得愈发重要。