我们发现了一种通过利用 Golang 构建缓存来加速并行 Golang 持续集成工作流的新方法。将 Git Hub 官方的 actions/setup-go 动作替换为 drop-in 等效方案，使我们的测试作业运行时间缩短了 69%。我们正在开源 cloudx-io/setup-go，让您也能这样做。Git Hub 的官方 actions/setup-go 步骤会导致并行作业相互干扰性能，并且会持续加载过期的缓存值。在我们的单体仓库中进行回测，这种常见的情况是几个并行的 Golang 测试作业（一个用于语法检查，一个用于测试，一个用于构建），表明默认动作所做的 86% 的工作是完全不必要的。如果您管理一个中等复杂度的 Go 项目，您可以期待类似的性能提升；请查看我们的 CI 测量方法论，或者直接尝试一下。我们非常重视快速的 CI。我们一直在大量推出新产品和功能，推出的速度实际上正在加快。这并非偶然——我们在使其可能所需的工具和流程上投入了大量精力。在每一个“软件工厂”的中心都是确保代码变更不会在生产环境中破坏的测试套件和持续集成（CI）工作流。如果我们的测试可靠且快速，并且在每次变更时快速运行，我们就可以以惊人的速度构建，而无需担心让客户的事情变得糟糕。这对我们很重要，所以我们会测量并投资于我们的 CI 作业的速度。如果您将代码推送到 Cloud X 仓库，我们的目标是让您在 90 秒内获得关于其可接受性的明确答案——无论是否构建、测试是否通过，以及是否遵守我们的 linter 规则。速度可以通过多种方式实现，但归根结底，如果您想让事情快速，就必须进行算法改进。我们已经使用 Warp Build 在快速、成本效益的机器上运行我们的 CI 作业。随着我们的测试套件随着我们的产品表面积而扩大，我们意识到 actions/setup-go 并没有让我们成功。

Git Hub 的 actions/setup-go 是 Git Hub 鼓励的在 Git Hub Actions 中安装和运行 Go 的方式。它在内部使用 actions/cache 来保存和恢复本地 Go 模块缓存和构建缓存目录。原则上，这应该使下载的模块源代码和来自一个作业的构建/测试构造得以供随后作业在您的仓库中运行使用。以下是默认 actions/setup-go 缓存键的构建：

此缓存键令人遗憾的是不完整：在一个典型的活跃开发产品中，只有极少量的代码变更会修改目标操作系统、架构、Go 版本或 go.mod 文件。第一次作业计算此哈希键时，它将最终的缓存状态持久化到 Git Hub 缓存服务。直到下一次修改了这些关键元素中的任意一个，每一次 CI 运行都会加载第一个值。随着您改变应用程序，从第一次运行中恢复的 Go 模块归档会变弱——每次后续构建从头开始做更多的工作。恢复的 Go 测