扩展自托管运行器

在现有的构建机器上安装 Action 运行器可以轻松迁移到 GitHub。但这不是一个长期解决方案！如果你不能使用 GitHub 提供的托管运行器，你应该自己构建一个具有弹性扩展能力的构建环境。

临时运行器

如果你为构建机器或容器构建一个弹性扩展解决方案，你应该使用瞬态（ephemeral）运行器。这意味着你使用一个虚拟机或 Docker 镜像，从空白镜像开始，安装一个临时的运行器。然后，在运行结束后，所有内容都会被清除。

不建议使用持久化运行器来构建弹性扩展的解决方案！

要将运行器配置为瞬态，你可以将以下参数传递给配置脚本：

$ ./config.sh --ephemeral

使用 GitHub Webhooks 实现上下扩展

要扩展虚拟环境的规模，你可以使用 GitHub Webhooks。workflow_job webhook 会在新工作流排队时被调用，并带有排队的 action 键。你可以利用此事件启动一个新的构建机器并将其加入机器池。工作流执行完成后，workflow_job webhook 会被调用并带有已完成的 action。你可以使用此事件来清理并销毁机器。

更多信息，请参阅 [文档](https://docs.github.com/en/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#workflow_job)。

现有解决方案

在 Kubernetes、AWS EC2 或 OpenShift 中构建弹性的虚拟构建环境超出了本书的范围。GitHub 本身并不提供这种解决方案，但 GitHub 上有许多开源解决方案可以节省你大量时间和精力，如果你想利用这些方案的话。Johannes Nicolai (@jonico) 已经整理了一个矩阵，列出了所有现有的解决方案。你可以在 [这个 GitHub 仓库](https://github.com/jonico/awesome-runners) 找到它，或者访问 [GitHub Pages 版本](https://jonico.github.io/awesome-runners)，矩阵会更加易读。该矩阵基于目标平台、是否支持 GitHub Enterprise、自动扩展能力、清理因素以及其他标准对解决方案进行了比较。

请记住，构建和运行一个可扩展的构建环境，使用自定义镜像，耗费大量时间和精力，这些时间和精力本可以用于其他事情。使用托管运行器是更便宜和更可持续的解决方案。在进行这样的投资之前，确保你真的需要在自己的平台上进行这样的建设。通常，除了托管自己的运行器外，还存在其他选择，例如将自己的 Docker 镜像带入 GitHub Actions，或使用机器人自动化部署到你的本地资源。