让我们聊聊 GitHub Actions
Source: GitHub Blog
概览
自 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 工作流中的重复配置。这使得你可以在多个工作流之间保持环境变量、步骤配置或整个作业设置的一致性——所有定义集中管理，而不是在多个作业中重复。
非公开工作流模板实现团队间一致的 CI
我们 发布了非公开工作流模板，这是一项 组织长期请求的功能，旨在提供一致且私密的工作流脚手架。
非公开工作流模板让组织可以在其 .github 仓库中直接设置通用模板，供团队使用，从而在创建新工作流时提供可靠的起点。团队不再需要手动在各仓库之间复制 CI 模式，而是可以基于共享的模板集合进行工作。
更深层次的可复用工作流，支持模块化、大规模流水线
我们 提升了可复用工作流的深度限制（又是一项 社区强烈需求的功能）。可复用工作流 让你能够将自动化拆分为模块化、可共享的片段。更新后的限制支持 10 层嵌套和每次运行最多 50 次工作流调用，团队可以更灵活地组织 CI/CD 流水线，使其更易维护并能随架构需求扩展。
更大的缓存容量，适配大型项目和依赖密集型构建
仓库现在可以突破之前的 10 GB 缓存上限，消除了大型依赖或多语言单体仓库团队长期面临的痛点。
对于代码基数大或构建流水线复杂的团队而言，旧的 10 GB 限制常导致构建依赖在下次工作流运行前被驱逐，进而出现重复下载、构建变慢的情况。此项发布满足了 社区的请求，尤其是我们最大的用户群体。
更多的 workflow_dispatch 输入，支持更丰富的自动化
在 12 月初，我们 将 workflow_dispatch 输入数量从 10 增加到 25，这一需求同样出现在 社区讨论中。现在开发者可以拥有更大的灵活性来构建复杂的自助工作流，无论是为部署参数化、配置测试运行，还是构建具备更丰富输入选项的可复用自动化。
💡 阅读文档，了解如何使用 workflow_dispatch 手动运行工作流
2025 年的更多性能和平台改进
我们还在今年早些时候奠定的坚实基础上取得了进展，包括：