每次想手动跑一次 CI，都要先 push 一个空提交——今天这件事被 workflow_dispatch 彻底变了

每次想手动跑一次 CI，都要先 push 一个空提交——这件事被 workflow_dispatch 彻底变了

大多数团队配 CI 都是 push 触发。但你可能遇到过这种场景：需要手动跑一次测试、临时部署一个分支、或者做一次生产数据库迁移，却不想留下无意义的 commit，也不想 merge，只能硬着头皮 git commit --allow-empty 推一个空提交。这件事今天被 GitHub Actions 的 workflow_dispatch + Environments 组合彻底原生化了。

三行配置，把 CI 变成可选”按钮”

在 workflow 文件里加一个触发器，就能在 GitHub 网页上看到一个”Run workflow”按钮：

name: Deploy
on:
  workflow_dispatch:
    inputs:
      environment:
        description: '部署环境'
        required: true
        type: choice
        options:
          - staging
          - production
      branch:
        description: '要部署的分支'
        required: true
        default: 'main'
      dry_run:
        description: '仅演练'
        type: boolean
        default: true

推上去之后，仓库的 Actions 页面会出现一个绿色按钮：Run workflow。点击之后会出现下拉框让你选环境、填分支、打勾dry_run。团队成员不需要懂 YAML，不需要 clone 代码，直接在网页上点几下就能触发一次定制化的流水线运行。

环境保护规则：给生产加一道审批门

光能手动触发还不够，生产环境需要一个审批关卡。GitHub Environments 允许你设置必须由谁审批才能继续：

Settings → Environments → New environment
Name: production
勾选 Required reviewers → 添加 @devops-team
勾选 Prevent self-review（防止触发者自己审批自己）

然后在 workflow 里指定 environment：

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production   # 引用刚刚创建的环境
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.inputs.branch }}
      - run: ./deploy.sh ${{ github.event.inputs.environment }}

配置好之后，即使有人通过 workflow_dispatch 触发了部署到 production，job 也会停在等待审批状态，直到 devops-team 的成员在 GitHub 页面上点 Approve 才能继续。

环境级 Secrets：生产密钥不再散落一地

之前配生产部署密钥，要么用仓库级 Secrets 全员可读（不安全），要么每套环境手动复制粘贴（容易出错）。Environments 允许你把密钥绑定到特定环境：

Settings → Environments → production → Environment secrets
添加 PROD_DB_URL
添加 PROD_API_KEY

这些密钥只在引用了 environment: production 的 job 中可见，引用 environment: staging 的 job 读不到。同一套 workflow 文件、两套密钥、物理隔离。

并发控制：防止两个人同时部署到同一环境

两个工程师同时点了 Run workflow，都选了 production，会不会打架？加一行 concurrency 配置就能防止：

concurrency:
  group: deploy-${{ github.event.inputs.environment }}
  cancel-in-progress: true

同环境的正在运行 job 会被自动取消，保留最新一次。

Wait Timer：多一层”反悔时间”

在环境保护规则里还有一个容易被忽略的选项：Wait Timer。设个 5-10 分钟，万一点错了，在这段时间内可以取消。这是很多团队没有但极其实用的安全网。

用 GitHub CLI 也能触发，连网页都不用开

对于习惯命令行的工程师，直接一行 CLI 搞定：

gh workflow run deploy.yml 
  -f environment=production 
  -f branch=feature/new-feature 
  -f dry_run=false

加 --wait 参数还能阻塞等待结果，不满意直接 Ctrl+C 取消。结合 jq 还能拿到 job ID 去做自动化集成。

三个坑，踩过才知道

坑一：workflow_dispatch 必须在默认分支才能触发。 如果你的 workflow 文件在 feature 分支，只有推到 main 之后才能用。这是 GitHub 的设计限制，不是 bug。

坑二：environment 名字不区分大小写，但引用必须完全匹配。 workflow 里写 environment: Production 但你创建的是 production，job 会直接失败且不提示原因。

坑三：Secrets 权限遵循”先审批再读取”原则。 在审批通过之前，job 连密钥的影子都看不到。这是安全特性，但如果你的 workflow 在审批之前就需要读取密钥做判断（比如判断要不要跳过），要提前想好解法。

三步下一步

第一步，先去 Actions 页面看看你现有哪些 workflow 还在靠 push 触发，可以改成 workflow_dispatch 让非技术成员也能用。

第二步，给 production 环境配一个 Required reviewers，2 人审批即可，不需要每次都找管理员。

第三步，把 dry_run 布尔参数加进去，让团队在正式部署前习惯先跑一遍演练。

现在去 Actions 页面找一个 workflow，加上 workflow_dispatch，试试点 Run workflow 是什么感觉。