Note
GitHub Enterprise Server 目前不支持 GitHub 托管的运行器。 可以在 GitHub public roadmap 上查看有关未来支持计划的更多信息。
关于 GitHub Enterprise Server 上的 GitHub Actions
本文介绍站点管理员如何配置 GitHub Enterprise Server 来使用 GitHub Actions。
GitHub Actions 默认情况下未为 GitHub Enterprise Server 启用。 您需要确定您的实例是否有足够的 CPU 和内存资源处理来自 GitHub Actions 的负载而不会造成性能损失，并可能增加这些资源。 还需要确定将哪个存储提供程序用于存储工作流运行生成的项目和缓存所需的 Blob 存储。 然后，您将为企业启用 GitHub Actions，管理访问权限，并添加自托管运行器以运行工作流程。
在开始之前，应制定一个计划，了解如何将 GitHub Actions 引入企业。 有关详细信息，请参阅“为企业引入 GitHub Actions”。
如果要将企业从其他提供商迁移到 GitHub Actions，则需要考虑其他注意事项。 有关详细信息，请参阅“将企业迁移到 GitHub Actions”。
检查硬件要求
可用于 你的 GitHub Enterprise Server 实例 的 CPU 和内存资源可确定在不造成性能损失的情况下可以配置的运行器数量。 GitHub 需要至少使用 8 个 vCPU 和 64 GB 内存来运行 GitHub Actions。
在没有性能损失的情况下连接运行器的高峰数量取决于作业持续时间限、构件使用、运行操作的存储库数量，以及实例所做的与操作无关的其他工作量等因素。 GitHub 的内部测试在一系列 CPU 和内存配置中证明了 GitHub Enterprise Server 的性能目标。
| vCPU | 内存 | 最大连接运行器数量 |
|---|---|---|
| 8 | 64 GB | 740 个运行器 |
| 32 | 160 GB | 2700 个运行器 |
| 96 | 384 GB | 7000 个运行器 |
GitHub 使用多个存储库、约 10 分钟的作业持续时间以及 10 MB 项目上传测得最大连接运行器数量。 您可能会经历不同的性能，具体取决于实例的总体活动水平。
Note
- 从 GitHub Enterprise Server 3.6 开始，GitHub 记录连接运行器，而不是并发作业。 连接运行器表示可以连接并预期会利用的最多数量的运行器。 还应该注意的是，连接的运行器数量超出预期数量可能会对性能产生负面影响。
- 从 GitHub Enterprise Server 3.5 开始，GitHub 的内部测试使用第三代 CPU 来更好地反映典型的客户配置。 CPU 中的这项更改表示此版本 GitHub Enterprise Server 中性能目标的一小部分更改。
如果您计划为现有实例的用户启用 GitHub Actions，请查看用户的活动级别和实例上的自动化，并确保已为用户预配足够的 CPU 和内存。 有关监视 GitHub Enterprise Server 的容量和性能的详细信息，请参阅“监视实例”。
有关 你的 GitHub Enterprise Server 实例 的最低硬件要求的更多信息，请参阅实例的平台的硬件注意事项。
有关为现有实例调整资源的详细信息，请参阅“增加存储容量”和“增加 CPU 或内存资源”。
（可选）可以通过为 GitHub Actions 配置速率限制来限制对 你的 GitHub Enterprise Server 实例 的资源消耗。 有关详细信息，请参阅“配置速率限制”。
外部存储要求
要在 GitHub Enterprise Server 上启用 GitHub Actions，您必须有权访问外部 Blob 存储。
GitHub Actions 使用外部 blob 存储来存储工作流运行生成的数据。 存储的数据包括工作流日志、缓存和用户上传的生成工件。 所需存储量取决于 GitHub Actions 的使用情况。 仅支持单个外部存储配置，不能同时使用多个存储提供程序。
所有其他 GitHub Actions 数据（例如存储库文件结构中的工作流文件）存储在 你的 GitHub Enterprise Server 实例 的数据存储卷上。
GitHub Actions 支持以下存储提供商：
- Azure Blob 存储
- Amazon S3
- Google 云存储
- 与 S3 兼容的 MinIO 群集
Note
只有这些是 GitHub 支持并可以提供帮助的存储提供程序。
还有其他与 S3 API 兼容的存储产品，GitHub 合作伙伴已经将它们自我验证为可以与 GitHub Actions 在 GitHub Enterprise Server 上运行。 有关详细信息，请参阅 GHES 存储合作伙伴存储库。
对于通过 GitHub 技术合作伙伴计划验证的存储产品，存储提供商负责为将存储产品与 GitHub Actions 配合使用提供支持和文档。
网络注意事项
如果为企业启用了 GitHub Actions，则仅支持 HTTP 代理。 不支持 SOCKS5 和 HTTPS 代理。 有关将代理与 GitHub Enterprise Server 配合使用的详细信息，请参阅“配置出站 Web 代理服务器”。
使用您的存储提供程序启用 GitHub Actions
请按照以下过程之一使用所选存储提供程序启用 GitHub Actions：
- 使用 Azure Blob 存储启用 GitHub Actions
- 使用 Amazon S3 存储启用 GitHub Actions
- 使用 Google 云存储启用 GitHub Actions
- 使用 MinIO 存储启用 GitHub Actions
管理企业中 GitHub Actions 的访问权限
您可以使用策略来管理 GitHub Actions 的访问。 有关详细信息，请参阅“在企业中为 GitHub Actions 实施策略”。
添加自托管的运行器
Note
GitHub Enterprise Server 目前不支持 GitHub 托管的运行器。 可以在 GitHub public roadmap 上查看有关未来支持计划的更多信息。
要运行 GitHub Actions 工作流程，您需要添加自托管运行器。 您可以在企业、组织或仓库级别添加自托管运行器。 有关详细信息，请参阅“添加自托管的运行器”。
管理哪些操作可用于您的企业
您可以控制允许用户在企业中使用哪些操作。 这包括设置 GitHub Connect 以自动访问来自 GitHub.com 的操作，或手动同步来自 GitHub.com 的操作。
有关详细信息，请参阅“关于在企业中使用操作”。
GitHub Actions
的一般安全性增强
若要详细了解有关 GitHub Actions 的安全做法，请参阅“GitHub Actions 的安全强化”。
保留名称
为企业启用 GitHub Actions 时，会创建两个组织：github 和 actions。 如果企业已使用 github 组织名称，则将改用 github-org（如果 github-org 也在使用中，则改用 github-github-org）。 如果企业已使用 actions 组织名称，则将改用 github-actions（如果 github-actions 也在使用中，则改用 github-actions-org）。 启用操作后，您将无法再使用这些名称。