GitHub Actions中repository_dispatch和workflow_dispatch的区别是什么
GitHub Actions 两种触发事件差异对比:repository_dispatch vs workflow_dispatch
核心差异对比
- 触发入口与主体不同:repository_dispatch 仅支持通过 GitHub REST API 调用触发,没有页面操作入口,多用于外部系统、其他仓库的自动化流程触发;workflow_dispatch 同时支持 API 触发和 GitHub 页面手动触发,页面入口在对应工作流的详情页顶部,有「Run workflow」按钮,多用于人工主动触发特定流程。
- 触发范围不同:单个 repository_dispatch 请求可以触发当前仓库内所有配置了对应事件类型的工作流;单个 workflow_dispatch 请求仅能触发指定的单个工作流文件。
- 参数规则不同:repository_dispatch 不需要提前在工作流中定义参数,调用 API 时传入的
client_payload字段内的所有内容都可以直接在工作流中引用;workflow_dispatch 必须提前在工作流的inputs字段中声明所有可接收的参数,包括参数类型、可选值、默认值等,未提前声明的参数即使传入也无法被工作流识别。 - 权限要求不同:触发 repository_dispatch 时,调用接口的认证 Token 需要有仓库的
repo作用域权限;触发 workflow_dispatch 时,页面操作需要用户有仓库的 Actions 写权限,API 调用需要 Token 有actions作用域权限。
真实使用场景举例
workflow_dispatch 适用场景:线上紧急回滚工作流
运维团队需要一个随时可触发的线上应用回滚流程,不需要修改代码、不需要提交推送,只需要填几个参数就能执行,就可以用workflow_dispatch实现。
配置示例:
name: 线上应用回滚 on: workflow_dispatch: inputs: target_version: description: '回滚目标版本号' required: true type: string deploy_env: description: '部署环境' required: true type: choice options: - staging - production skip_verify: description: '是否跳过健康检查' type: boolean default: false jobs: rollback: runs-on: ubuntu-latest steps: - name: 执行回滚 run: echo "正在将${{inputs.deploy_env}}环境回滚到版本${{inputs.target_version}}" # 后续实际回滚、校验逻辑
出现线上故障时,运维同学直接打开对应工作流页面,选择要回滚的环境、填版本号,按需勾选跳过健康检查,点击按钮就可以直接启动回滚流程,效率极高。
repository_dispatch 适用场景:跨仓库依赖自动联动校验
团队维护了一个公共组件库仓库,同时有12个业务仓库依赖这个组件库,每次组件库发布新版本,需要所有业务仓库自动更新依赖版本、跑单元测试校验兼容性,就可以用repository_dispatch实现跨仓库联动。
首先在组件库的发版工作流最后,添加调用接口的步骤,给所有业务仓库发送component_release类型的repository_dispatch事件,携带新版本号参数。
业务仓库侧的工作流配置示例:
name: 公共组件兼容性校验 on: repository_dispatch: types: [component_release] # 只处理指定类型的触发事件 jobs: verify: runs-on: ubuntu-latest steps: - name: 更新组件版本 run: echo "将组件版本更新为${{github.event.client_payload.new_version}}" # 后续更新依赖、执行测试、自动提PR逻辑
每次组件库发版,所有业务仓库的校验工作流都会自动触发,不需要人工逐个操作,也不需要给组件库开通所有业务仓库的工作流操作权限,安全性和效率都能得到保障。
内容的提问来源于stack exchange,提问作者Sajith Mantharath
相关产品推荐
相关产品推荐

