技术速递|让我们聊聊 GitHub Actions
作者:Ben De St Paer-Gotch 本文将带大家了解,我们如何重构 GitHub Actions的核心架构,并推出一众呼声已久的升级功能,以此提升工具性能、增强工作流灵活性、提高系统可靠性,同时优化开发者的日常使用体验。自 2018 年发布以来,GitHub Actions 已取得飞速发展;仅在 2025 年,开发者在公共和开源项目中就使用了 115 亿分钟的 GitHub Actio
作者:Ben De St Paer-Gotch 本文将带大家了解,我们如何重构 GitHub Actions
的核心架构,并推出一众呼声已久的升级功能,以此提升工具性能、增强工作流灵活性、提高系统可靠性,同时优化开发者的日常使用体验。
自 2018 年发布以来,GitHub Actions 已取得飞速发展;仅在 2025 年,开发者在公共和开源项目中就使用了 115 亿分钟的 GitHub Actions,较 2024 年同比增长 35%。与此同时,这一增长过程也伴随着一些挑战,而你们清楚地告诉了我们最迫切需要改进的方面:更快的构建、更强的安全性、更好的缓存、更灵活的工作流,以及坚如磐石的可靠性。
要满足如此高的需求,首先需要对支撑每个 GitHub Actions 任务和运行器的核心后台服务进行精心的架构重构。这是一次规模庞大的努力,为你们所期待的长期性能、可扩展性和功能交付奠定了基础。新的架构现已上线,每天处理 7100 万个任务,同时让我们对平台上的开发者体验有了更深入的可视化了解。
完成这项工作后,我们将注意力重新回到你们最关心的、急需的长期生活质量改进上。接下来,我们将介绍今年已推出的功能、如何立即开始使用这些升级,以及 2026 年的计划。
让我们直接开始吧。
重建 GitHub Actions 核心架构
在 2024 年初,GitHub Actions 团队面临一个问题。平台每天大约运行 2300 万个任务,但月度持续增长清楚地表明:现有架构无法可靠支撑我们的增长曲线。为了提升功能迭代速度,我们首先需要提高可靠性,并对支撑 GitHub Actions 的老旧框架进行现代化改造。
解决方案? 对支撑 GitHub Actions 任务和运行器的核心后台服务进行重构。
我们的目标是:
- 提高正常运行时间和抵御基础设施问题的恢复能力
- 提升性能并减少内部限流
- 利用 GitHub 更广泛的平台投资和开发者体验改进
我们计划在现有使用量基础上实现 10 倍扩展。这一努力是一项重大赌注,也占用了团队大量精力。如今,这项工作正在收获成效,帮助我们应对当前规模的任务,同时继续完成新平台最后的稳定化工作。
自 8 月起,所有 GitHub Actions 任务都已在新架构上运行,每天处理 7100 万个任务(是最初的 3 倍以上)。单个企业每分钟能够启动的任务数量,比之前的架构支持的数量多 7 倍。
当然,这一过程并非没有痛点:它放慢了新功能的开发速度,也延迟了长期社区请求的进展。我们知道这是一个艰难的决定,但这是确保未来产品路线图和可持续性发展的关键步骤。
将关注点重新回到社区需求的改进上
我们也清楚,前进的道路仍然很长,这只是 GitHub Actions 新篇章的起点。在我们将注意力重新转向迫切需要的改进时,想先向大家介绍一些近期在这方面已推出的重要功能:
YAML 锚点减少复杂工作流中的重复配置
首先,我们推出了 YAML 锚点支持,这是运行器和社区仓库中最受欢迎的功能之一。YAML 锚点通过让你使用锚点(&) 定义一次设置,并在其他地方通过别名(*) 引用,从而减少 GitHub Actions 工作流中的重复配置。这使你能够在整个工作流中保持一致的环境变量、步骤配置,甚至完整的任务设置——所有内容都集中定义,而无需在多个任务中重复书写。
💡 阅读我们的文档,了解更多关于 YAML 锚点和别名的信息
非公开工作流模板,让团队 CI 更加一致
我们推出了非公开工作流模板,这是许多希望获得一致且私有工作流骨架的组织长期以来的需求。
非公开工作流模板允许组织在其 .github 仓库中为团队设置通用模板,让开发者在创建新工作流时拥有可靠的起点。团队无需再手动在各个仓库间复制 CI 模式,而是可以直接使用共享的模板集合。
💡 阅读我们的文档,了解更多关于工作流模板的信息
更深层的可重用工作流,支持模块化大规模流水线
我们提升了可重用工作流的嵌套深度(这是社区的另一项重要需求)。可重用工作流允许你将自动化拆分为模块化、可共享的部分。通过更新后的限制——每次运行支持 10 级嵌套和 50 次工作流调用——团队现在可以更灵活地构建可维护且符合架构要求的 CI/CD 流水线。
💡 阅读我们的文档,了解更多关于可重用工作流的信息
为更大的项目和依赖密集型构建提供更大的缓存
仓库现在可以突破之前 10GB 的缓存限制,为那些拥有大量依赖或多语言单体仓库的团队解决了一个长期存在的痛点。
对于拥有大规模代码库或复杂构建流水线的团队来说,以前 10GB 的 GitHub Actions 缓存限制往往导致构建依赖在下次工作流运行前被清除,从而重复下载、构建变慢。这次发布得以实现,正是得益于我们对架构的重构,也满足了社区的请求,尤其是我们的一些最大型用户的需求。
💡 阅读我们的文档,了解更多关于缓存管理的信息
更多工作流调度输入,打造更丰富的自动化
在 12 月初,我们将工作流调度输入数量从 10 增加到 25,这也是社区讨论中提出的需求。现在,开发者可以更灵活地构建复杂的自助式工作流,无论是团队在参数化部署、配置测试运行,还是利用更丰富的输入选项构建可重用的自动化流程。
💡 阅读我们的文档,了解更多关于通过工作流调度手动运行工作流的信息
2025 年推出的更多性能和平台改进
我们还在今年早些时候奠定的坚实基础上取得了进展,包括:
这些发布旨在提升日常工作流的质量,并消除长期存在的使用摩擦。
2026 年初会有什么新内容?
这仅仅是一个开始,我们仍有大量工作要做,才能为 GitHub Actions 带来更出色的体验。以下是我们计划在 2026 年第一季度推出的内容,这些规划参考了社区的一些主要需求:
- 为定时任务提供时区支持,并提升调度的可靠性
- 从工作流调度中返回运行 ID
- 为表达式新增 case 函数,提供条件运算符或条件函数能力
- 用户体验改进,包括更快的页面加载速度、对包含 300+ 任务的工作流提供更好的渲染效果,以及任务列表筛选功能
此外,我们还将启动并行步骤的开发工作,这是 GitHub Actions 中呼声最高的功能之一,目标是在 2026 年年中之前正式发布。最后,我们也将进一步提高标准,开始响应社区关于提升开源仓库质量的诉求。我们深知,在这一点上,同样需要持续改善整体使用体验。
帮助我们共同塑造 GitHub Actions 的 2026 路线图
GitHub Actions 是 GitHub 上最重要的基础能力之一,支撑着当今软件交付过程中至关重要的构建、测试、部署、自动化和发布流程。
我们对大家的承诺是:2026 年将带来更稳定的版本发布、更高的透明度,并持续聚焦最重要的基础能力。同时,我们也将加大在这一领域的投入,以比以往更快地满足你的期望。
而这正是我们需要你参与的地方——帮助我们确保把精力放在最有价值的体验优化改进上。我们需要你的反馈。你可以通过以下方式支持我们的工作:
- 持续在社区讨论中为你认为最重要的事项投票
- 参与我们新的社区讨论帖,GitHub Actions 的产品和工程负责人将与你直接交流接下来要做什么
- 帮助我们共同制定明年的计划,让 Actions 变得尽可能好
我们深知,GitHub Actions 决定了开发者如何构建软件,而它的最佳形态,必然是我们与社区一起打造的版本。一如既往,你也可以通过 GitHub Changelog 随时了解 GitHub Actions 的最新发布动态。
更多推荐
所有评论(0)