GitHub Actions的pull_request事件触发失败，求排查方向

• 检查团队仓库的Actions权限配置
  进入仓库的Settings → Actions → General页面，重点确认：

  • 是否开启了允许来自fork的PR触发工作流（对应选项大概是“Allow GitHub Actions to run on pull requests from forks”类的表述）
  • 确认Workflow permissions的设置，至少要有读权限，若需要写操作则设为“Read and write permissions”
  • 检查是否勾选了允许GitHub官方Actions运行，避免因权限拦截导致工作流不触发

• 核对工作流文件的位置和命名
  确保工作流文件存放在.github/workflows/目录下，文件名后缀是.yml或.yaml，没有路径拼写错误（比如少写了workflows的s）或后缀错误

• 查看Actions历史记录的跳过原因
  进入团队仓库的Actions页面，查找是否有被标记为“skipped”的工作流记录，点进去查看具体跳过原因——GitHub会在这里说明是权限问题、事件不匹配还是其他安全策略导致的

• 检查分支保护规则的影响
  进入仓库Settings → Branches → Branch protection rules，确认有没有设置过于严格的推送限制，或者是否在“Require status checks to pass before merging”里误设了拦截规则（不过这个更多影响合并而非触发，但可以排查）

• 确认PR的触发场景细节
  再次核对PR的基本信息：源分支确实来自你的fork仓库，目标分支是团队仓库的正确分支；新建/重新打开PR的操作确实触发了pull_request事件的默认触发条件（opened/reopened）

• 排查GitHub安全策略的拦截
  pull_request事件处理fork的PR时权限限制更严格，如果仓库全局设置了禁止fork PR触发工作流，就会出现只有pull_request_target能触发的情况——这是最可能的原因，重点优先排查第一点的权限设置

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