GitHub Actions 环境保护规则怎样要求人工批准

如果生产部署不能由工作流触发后立即执行，可以把部署 job 绑定到 GitHub Environment，再为这个环境添加 Required reviewers。这样工作流进入该 job 后会先停在 Waiting，指定用户或团队批准后才继续执行部署步骤。

官方地址：https://github.com/

最短配置路径：仓库的 Settings → Environments 新建或打开环境，在 Deployment protection rules 中添加 Required reviewers；然后让工作流的部署 job 写入 environment: production。提交工作流后，先看到 Waiting，再由有权限的审阅者批准。下面的界面图是原创操作说明图，不是 GitHub 的实际截图。

先确认 Environment 与审批权限

人工批准规则配置在仓库 Environment 上，不是普通分支保护规则。先进入目标仓库的 Settings，在左侧找到 Environments，新建或打开例如 production 的环境。

Required reviewers 可以填写用户或团队，最多列出六个审阅者；工作流进入该环境后，其中一个 required reviewer 批准即可继续。审阅者至少要对仓库有读取权限。若要让生产发布始终由另一个人确认，还要关注 Prevent self-review，它会阻止触发部署的人批准自己的部署。

计划和仓库可见性也会影响可用范围。GitHub 文档当前说明，Environment 及其保护规则在公开仓库可用；私有或内部仓库对计划有额外要求。配置前先确认仓库权限和计划，不要把“看到了设置项”误认为所有仓库都能按同样方式执行。

在环境中添加 Required reviewers

1. 打开仓库的 Settings → Environments，选择 production。
2. 在 Deployment protection rules 区域点击添加审阅者。
3. 选择一个或多个用户、团队，并按需要开启 Prevent self-review。
4. 保存保护规则；如果同时配置了分支或标签限制，后续还要确保工作流引用的 ref 满足这些条件。

这里的关键不是把某个名字写进 YAML，而是让环境本身拥有保护规则。用户或团队名称属于仓库协作配置，工作流只负责声明“这个 job 要进入哪个环境”。

让部署 job 引用受保护环境

在工作流的部署 job 上填写环境名称。下面是一个最小示例：它先运行构建 job，再让部署 job 进入 production。代码中的中文注释说明了依赖关系与门禁位置。

name: deploy

on:
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Build
        run: echo "构建产物"

  deploy:
    needs: build # 先完成构建，再进入生产环境门禁
    runs-on: ubuntu-latest
    environment:
      name: production # 必须与 Settings 中的 Environment 名称完全一致
    steps:
      - name: Deploy
        run: echo "执行部署步骤" # 审批通过后才会运行这里

environment.name 要和仓库设置中的环境名一致。工作流只是引用环境；真正的 Required reviewers、分支限制和等待规则由 Environment 配置决定。如果名称写错，job 可能进入另一个环境或创建出不带预期保护规则的环境。

从 Waiting 状态完成一次人工批准

把工作流提交到仓库后，打开对应的 Actions 运行记录。构建 job 完成后，引用 production 的部署 job 应显示为等待审核，而不是直接进入下一步。进入该 job 的审核入口，确认工作流、分支和变更范围，再选择批准或拒绝。

批准前，部署 job 的后续步骤不会继续执行；批准后，job 才会按原工作流继续。如果拒绝，部署任务不会通过这个环境门禁。若长时间无人处理，也不能把 Waiting 当作构建失败，应先确认审阅者通知、仓库权限和环境名称。

GitHub 文档说明，等待审核的 job 如果在 30 天内没有获批，会自动失败。因此生产门禁需要配合团队值班或发布节奏安排审阅者，避免审批请求无人处理。

常见配置问题与最终确认

为什么部署没有出现 Waiting？先检查部署 job 是否写了 environment，名称是否完全匹配，并确认 Required reviewers 保存到了同一个仓库环境。只配置环境变量或普通 job 名称，不会自动触发人工审批。

为什么触发人不能批准？检查环境的 Prevent self-review 是否开启。开启后需要另一个符合条件的审阅者批准，这是防止发起人自己绕过门禁的预期行为。

多个审阅者是不是都要批准？不是。Required reviewers 可以列出多个用户或团队，但当前规则是其中一个符合条件的审阅者批准即可继续。

最后按这三点确认配置完成：Environment 名称与 YAML 一致；保护规则中能看到 Required reviewers；Actions 运行记录在部署 job 处先出现 Waiting，批准后才进入部署步骤。这样人工批准真正成为发布门禁，而不是只停留在设置页面。