GitHub Action工作流误被push触发未响应Issue事件排查

• 非默认分支留存了错误版本的工作流文件：GitHub Actions 不会只读默认分支的工作流配置，哪个ref（分支/标签）上触发了事件，就读取哪个ref下存的.github/workflows里的配置。如果异常仓库的非默认分支上还留着之前写错的同名工作流，旧配置里on字段错加了push触发，那往这些分支推代码的时候，自然会加载错误配置触发运行；如果改对的配置只存在于默认分支，没同步到其他开发分支，就会出现触发逻辑完全不对的情况，这也是这类半对半错问题最常见的原因。
• 仓库Actions权限配置不统一：异常仓库的Actions全局设置可能关了Issue事件触发工作流的权限，要么是仓库设置里的Actions通用配置做了限制，要么是上层组织的安全策略拦截了Issue触发的工作流，导致你写的issues触发规则根本不生效。
• 配置本身有YAML语法不规范的问题：你贴的配置里，第一步的labeled参数写法不对，多个标签值没有按YAML数组格式写，直接写labeled: "Type: Enhancement", "Type: Bug"属于语法错误，部分场景下YAML解析器容错失败，会出现触发规则识别错乱的问题。正确的多标签写法应该用数组格式：

labeled:
  - "Type: Enhancement"
  - "Type: Bug"
label-operator: OR

• Token权限不足导致运行失败：你用的actions/add-to-project是操作GitHub Project的，配置里的github-token如果没开Project V2的写入权限，就算工作流被Issue事件正常触发，执行的时候也会直接失败，很容易被误判成“根本没触发”。

• 先核对每次运行加载的工作流版本：打开任意一次工作流运行的详情页，顶部都会显示这次跑的工作流属于哪个分支、对应哪个提交版本，直接点进去看文件内容，就能立刻确认是不是加载了其他分支上的旧错误配置，这是最快的排查手段。
• 打印触发上下文实锤触发源：在工作流最开头加一个打日志的步骤，直接输出真实的触发事件和加载的分支信息，配置参考：

steps:
  - name: 打印触发上下文
    run: |
      echo "触发事件: ${{ github.event_name }}"
      echo "加载配置的ref: ${{ github.ref }}"

跑完看日志就知道到底是push触发的还是issues触发的，不会被页面上的展示信息误导。

• 开调试日志看配置解析全流程：在仓库的Secrets里加一个名为ACTIONS_STEP_DEBUG的密钥，值设为true，之后再跑工作流就能看到 debug 级别的日志，里面会完整记录GitHub怎么解析你写的on字段、怎么匹配触发规则，能直接定位配置解析异常的根因。
• 做基准配置对比：拿能正常运行的仓库当模板，逐项对比异常仓库的Actions权限、分支保护规则、工作流文件内容、使用的token权限，把不一样的地方改齐基本就能解决问题。

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