环境和部署

部署保护规则

部署保护规则要求通过特定的条件，然后引用环境的作业才能继续。可以使用部署保护规则来要求人工审批、延迟作业或将环境限制于某些分支。还可以创建并实现由 GitHub Apps 提供支持的自定义保护规则，以使用第三方系统控制引用 GitHub 上配置的环境的部署。

第三方系统可以是可观测性系统、变更管理系统、代码质量系统或其他手动配置，用于在将部署安全部署到环境之前评估就绪情况。

注意

可以在存储库中安装任意数量的基于 GitHub Apps 的部署保护规则。但是，最多可以同时在环境中启用 6 个部署保护规则。

使用所需的审查者要求特定人员或团队批准引用环境的工作流程作业。您最多可以列出六个用户或团队作为审查者。审查者必须至少具有对仓库的读取访问权限。只有一个必需的审查者需要批准该作业才能继续。

也可以选择阻止对受保护环境中的部署进行自评审。如果启用此设置，则启动部署的用户将无法批准部署作业，即使他们是必需的审阅者也是如此。这可确保受保护环境中的部署始终经过多人评审。

有关由必需审查者审查引用环境的作业的详细信息，请参阅“审查部署”。

在最初触发作业后，使用等待计时器将作业延迟特定时间。时间（分钟）必须是 1 至 43,200（30 天）之间的整数。等待时间不会计入可计费时间。

使用部署分支和标记来限制哪些分支和标记可以部署到环境中。以下是环境部署分支和标记的选项：

无限制****：对于可以部署到环境中的分支或标记无限制。
仅限受保护的分支：只有启用了分支保护规则的分支才能部署到环境****。如果没有为仓库中的任何分支定义分支保护规则，那么所有分支都可以部署。有关分支保护规则的详细信息，请参阅“关于受保护分支”。

注意

部署工作流运行由与受保护分支同名的标记触发，并且与受保护分支名称匹配的分支无法部署到环境中。
所选分支和标记：只有与指定名称模式匹配的分支和标记才能部署到环境****。

例如，如果指定 releases/* 为部署分支或标记规则，则只有名称以 releases/ 开头的分支或标记才能部署到环境。（通配符不匹配 /。若要匹配以 release/ 开头并包含额外单斜杠的分支或标记，请使用 release/*/*。）如果将 main 添加为分支规则，则名为 main 的分支也可以部署到环境中。有关部署分支的语法选项的详细信息，请参阅 Ruby File.fnmatch 文档。

注意

必须单独为分支或标记配置名称模式。

默认情况下，管理员可以绕过保护规则，并强制部署到特定环境。有关详细信息，请参阅“审查部署”。

或者，可以将环境配置为禁止绕过环境的所有部署保护规则。

注意

自定义部署保护规则目前为公共预览版，可能随时更改。

可以启用自己的自定义保护规则来限制第三方服务的部署。例如，可以使用 Datadog、Honeycomb 和 ServiceNow 等服务为部署到 GitHub 提供自动审批。有关详细信息，请参阅“创建自定义部署保护规则”。

在存储库上创建自定义部署保护规则并安装后，可以为存储库中的任何环境启用自定义部署保护规则。有关配置和启用自定义部署保护规则的详细信息，请参阅“配置自定义部署保护规则”。

存储在环境中的机密仅可用于引用环境的工作流程作业。如果环境需要批准，作业在所需的审查者批准之前不能访问环境机密。有关机密的详细信息，请参阅“机密”。

注意

在自托管运行器上运行的工作流不会在一个孤立的容器中运行，即使它们使用环境。环境机密应与存储库和组织机密的安全级别相同。有关详细信息，请参阅“安全使用参考”。

存储在环境中的变量仅可用于引用环境的工作流作业。只能使用 vars 上下文访问这些变量。有关详细信息，请参阅“在变量中存储信息”。