如何在下游调用的GitHub Actions工作流失败时接收通知？

针对你在组织内集中管理共享工作流、需要接收下游调用失败通知的需求，有两种可行方案：

方案一：在共享工作流中嵌入失败通知步骤 #

直接在你维护的my-action-script.yml中添加一个仅在工作流失败时触发的步骤，通过GitHub API在你的共享仓库中创建issue——作为共享仓库的维护者，你会自动收到该issue的通知。

示例配置如下：

jobs:
  core-task:
    runs-on: ubuntu-latest
    steps:
      # 原有业务步骤
      - name: 执行核心任务
        run: echo "处理业务逻辑"
      
      # 失败触发通知
      - name: 发送调用失败通知
        if: failure()
        uses: actions/github-script@v6
        with:
          script: |
            await github.rest.issues.create({
              owner: context.repo.owner,
              repo: '你的共享仓库名称',
              title: `工作流调用失败：${context.payload.repository.full_name}`,
              body: `仓库地址：${context.payload.repository.html_url}\n工作流运行ID：${context.runId}\n触发事件：${context.eventName}`
            })

优势：无需下游团队配合，配置一次即可覆盖所有调用方；无需关注下游仓库，依赖共享仓库的issue通知机制即可接收提醒。
注意：若调用量较大，共享仓库会产生较多issue，建议添加标签分类或定期归档。

方案二：使用组织级Webhook统一监听 #

在组织设置中创建Webhook，监听workflow_run事件，当任意仓库的工作流运行失败时，通过Webhook接收请求并过滤出调用了你共享工作流的失败案例，再转发到你的通知渠道（如邮件、Slack等）。

配置要点： #

1. 进入组织设置 → Webhooks → 添加Webhook
2. 设置Payload URL为你的通知服务地址（可自行搭建简单服务或使用自动化工具）
3. 选择事件为Workflow runs
4. 在接收端逻辑中，判断workflow_run.conclusion为failure，并检查下游工作流的配置中是否包含对你共享工作流的uses引用（可通过GitHub API拉取下游工作流文件内容验证）

优势：不会污染共享仓库的issue，可统一管理所有失败通知；覆盖组织内所有仓库，无需逐个配置。
劣势：需要维护Webhook接收服务，有一定技术门槛。

内容的提问来源于stack exchange，提问作者Drew Wilson