GitHub Actions首个流水线成功后，第二个workflow_run未触发

针对你遇到的第一个工作流成功完成，但第二个workflow_run触发的工作流未启动的问题，可以从以下几个方向排查：

1. 检查第二个工作流的文件位置与格式 #

GitHub Actions 要求工作流文件必须放在仓库根目录下的 .github/workflows/ 文件夹中，且文件后缀必须是 .yml 或 .yaml。如果第二个工作流的文件路径错误（比如放在了其他文件夹），或者后缀是 .txt 等非标准格式，GitHub 会无法识别该工作流，自然不会触发。

2. 核对工作流名称的完全匹配 #

第二个工作流的触发规则中，workflows 列表里的名称必须和第一个工作流的 name 字段完全一致，包括空格、大小写、特殊符号：

# 第二个工作流中的配置
on:
  workflow_run:
    workflows:
      - "CI + SonarQube Analysis" # 必须和第一个工作流的name完全相同

检查是否存在拼写错误、全角/半角空格混用、大小写不一致的情况（比如把 CI 写成 ci）。

3. 确认第一个工作流的触发事件是否符合要求 #

workflow_run 触发规则默认不会对**拉取请求（pull_request）**事件中的工作流触发后续工作流，除非显式配置分支过滤规则。你的第一个工作流在 pull_request 事件（目标分支为main）下也会运行，但此时第二个工作流可能不会被触发。

如果你的第一个工作流是通过 pull_request 事件触发并完成的，需要修改第二个工作流的触发规则，添加分支过滤：

on:
  workflow_run:
    workflows:
      - "CI + SonarQube Analysis"
    types:
      - completed
    branches: [main] # 添加分支过滤，确保目标分支匹配

4. 检查仓库的Actions权限设置 #

进入仓库的「Settings」→「Actions」→「General」页面，确认以下权限：

• 在「Workflow permissions」部分，确保设置为「Read and write permissions」，避免权限不足导致无法触发后续工作流
• 确认未启用限制工作流触发的安全策略

5. 排查工作流运行的上下文限制 #

如果第一个工作流是在fork仓库中运行的（比如外部贡献者的PR），GitHub 出于安全考虑，不会触发原仓库中的第二个工作流。这种情况下，只有原仓库main分支的push事件或手动触发的工作流，才能触发后续的workflow_run工作流。

6. 查看GitHub Actions的日志与事件记录 #

进入仓库的「Actions」页面，点击第一个工作流的运行记录，查看页面底部的「Events」标签，确认是否有触发第二个工作流的事件记录。如果没有，说明触发规则不满足；如果有但第二个工作流未启动，查看是否有被GitHub安全策略拦截的提示。

内容的提问来源于stack exchange，提问作者kiran itagi