你以为 GitHub Actions 只能等着 push 触发？今天外部系统把这件事直接接管了

每次改完代码 push 上去，等 CI 跑完再手动触发部署——这套流程配了三年，今天发现根子不在要不要自动化，是 GitHub Actions 的触发器一直只等着 push 这一个来源。

GitHub Actions 支持三种外部触发方式，这个能力今天被大多数团队完全忽略了。

repository_dispatch：外部系统发请求触发工作流

这是 GitHub 官方留的外部入口。外部系统只要调一行 curl，就能触发任意 GitHub Actions 工作流：

curl -X POST 
  -H "Authorization: token $PAT" 
  -H "Accept: application/vnd.github+json" 
  https://api.github.com/repos/OWNER/REPO/dispatches 
  -d '{"event_type": "deploy-requested", "client_payload": {"env": "production"}}'

工作流侧只需要监听这个事件类型：

on:
  repository_dispatch:
    types: [deploy-requested]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploying ${{ github.event.client_payload.env }}"

client_payload 最多传 10 个顶层属性、65535 字符，足够装下环境、版本、触发源等完整上下文。注意：GITHUB_TOKEN 不能触发 repository_dispatch，必须配一个有 repo 范围的 Personal Access Token（PAT），存进 Secrets。

workflow_dispatch：手动触发但可以传参

在 GitHub 网页上手点触发是最常见的用法，但它的价值在于可以带参数：

on:
  workflow_dispatch:
    inputs:
      environment:
        description: '部署环境'
        required: true
        type: choice
        options: [staging, production]
      version:
        description: '版本号'
        required: true

配合 peter-evans/workflow-dispatch Action，还可以通过另一个工作流触发它，实现 CI → CD 的链式调用。但这里有个关键坑：workflow_dispatch 只能触发默认分支上的工作流文件。

Webhook 失败自动重传：GitHub Actions 帮你写好了脚本

外部系统触发最怕的就是 webhook 发出去但 GitHub 没收到。GitHub 官方文档里有完整方案：用 Actions 跑一个定时脚本，自动扫描 webhook 交付记录，把失败的重新投出去。核心逻辑是调 /repos/{owner}/{repo}/hooks/{hook_id}/deliveries/{delivery_id}/attempts 这个 API，配合 PAT + Octokit SDK，每 6 小时扫一遍，丢多少次重传多少次。

这条链路打通了，意味着部署可以完全由外部系统（监控系统、发布平台、定时任务）发起，GitHub Actions 只是执行器，状态全在 GitHub 这边留档。

配了三年 GitHub Actions，今天才发现这三个触发方式一直没配到位

repository_dispatch 是最被低估的一个——它把 CI/CD 的入口从「谁来 push 代码」变成了「谁来发请求」，发布平台、监控告警、定时批跑全部可以绕过 GitHub 页面直接触发工作流。workflow_dispatch 不只是手动点按钮，配合矩阵策略可以做跨仓库链式触发。workflow_dispatch + workflow_run 组合，则可以实现「主流程跑完自动跑下游」而不需要任何第三方调度器。

下一步：打开你的仓库设置，找到 Webhooks 页面，把 repository_dispatch 的触发地址配进你的发布平台。5 行配置，换来的是整个部署链路的状态可追溯和审计日志完整留存。