GitHub 近期的一次数据库备份故障凸显了一个常见问题：CI 工作流运行缓慢或失败。与 outright 失败不同，缓慢的运行往往未被察觉，导致资源浪费。对热门开源仓库的扫描显示，其 CI 配置存在广泛的低效现象。许多项目缺少关键的设置，如并发控制和作业超时，从而导致工作流冗余。一个显著的问题是同时在推送（push）和拉取请求（pull request）上触发工作流，导致同一变更产生重复运行。这可以通过仅在非默认分支上针对拉取请求触发来解决。另一个常见问题是未能取消正在进行的运行，当新代码被推送时，会导致队列槽位浪费。实施并发组并将 cancel-in-progress 设置为 true 可防止此问题。每次运行都从头重新安装依赖也会增加 considerable 时间。利用 setup actions 中的缓存功能可显著加速此过程。过度庞大的矩阵（即在每个操作系统版本组合上运行测试）可以通过为拉取请求运行精简矩阵、为默认分支或夜间构建运行完整矩阵来优化。未将 CI 触发器限定于特定文件路径意味着任何变更，即使是文档中的拼写错误，也可能触发整个测试套件。此外，未设置超时的作业可能挂起数小时，消耗过多资源。为每个作业设置 timeout-minutes 至关重要。已有工具可用于扫描公共仓库并识别这些常见的 CI 低效问题。检查热门项目的 Actions 评分卡（Actions scorecards）也可提供最佳实践的见解。作者提供了一个免费扫描器，以帮助在任何公共仓库中识别这些模式。