GitHub提交PR未显示continuous-integration/jenkins/pr-merge检查问题排查

背景 #

在GitHub Enterprise中，组织A下有项目A。当向项目A提交PR（拉取请求）时，会触发continuous-integration/jenkins/pr-merge检查，运行Jenkins流水线完成代码构建和单元测试，若单元测试失败则禁止PR合并到master分支。

包含损坏单元测试的项目A的GitHub PR页面展示如下：

现在尝试对组织B下的项目B配置相同规则，但配置未生效。包含损坏单元测试的项目B的GitHub PR页面展示如下：

可以看到项目B的PR没有启动continuous-integration/jenkins/pr-merge检查。

项目A与项目B配置详情 #

GitHub -> Settings -> Branches -> Branch protection rules（分支保护规则） #

GitHub上项目A的master分支保护规则仅启用了一项配置：

• Require pull request reviews before merging（合并前需经过PR评审）
  值得注意的是，项目A未启用「Require status checks to pass before merging（合并前需通过状态检查）」配置，点开该配置（未保存）时，可以看到continuous-integration/jenkins/pr-merge出现在可选检查列表中。
  项目B的master分支配置了完全相同的分支保护规则，仅启用「合并前需经过PR评审」。当点开「合并前需通过状态检查」配置（未保存）时，可选列表中甚至没有continuous-integration/jenkins/pr-merge选项，仅显示*「No status checks found. Sorry, we couldn’t find any status checks in the last week for this repository.（未找到状态检查，抱歉，我们无法找到该仓库过去一周内的任何状态检查）」*。

GitHub -> Settings -> Hooks -> Webhooks #

GitHub上项目A配置的webhook参数如下：

• Payload URL：https://jenkins.mycompany.com/github-webhook/
• Content type：application/json
• 触发事件选择自定义事件，勾选了Pull requests、Pushes、Repositories三类事件
• Active（启用状态）：已勾选
  项目B创建了参数完全相同的webhook，提交项目B的PR后，查看webhook的「Recent Deliveries（最近交付记录）」有多个带绿色对勾、返回码200的记录，因此判断webhook配置正常。

CloudBees Jenkins Enterprise配置 #

Jenkins Enterprise中项目A的流水线类型为「GitHub Organization」，配置如下：

• API endpoint：kubernetes-cbs-automation（https://git.mycompany.com/api/v3）
• Credentials：[项目A专属凭证]
• Owner：[项目A对应的GitHub组织]
• Behaviors（行为）：Repositories（仓库）：按名称过滤（正则表达式）：正则表达式：[项目A的GitHub仓库名称]
• Behaviors（行为）：仓库内规则：Discover pull requests from origin（发现来自源仓库的PR）：策略：将PR与当前目标分支版本合并
• Project Recognizers（项目识别器）：Pipeline Jenkinsfile：脚本路径：ci-cd/jenkins/ProjectA-pipeline.groovy
• Property strategy（属性策略）：所有分支使用相同属性
• Scan Organization Triggers（组织扫描触发规则）：勾选「无其他触发时定期扫描」，间隔1天
• Orphaned Item Strategy（孤儿项目策略）：勾选「丢弃旧项目」
• Child Orphaned Item Strategy（子项目孤儿策略）：策略：继承
• Child Scan Triggers（子项目扫描触发规则）：勾选「无其他触发时定期扫描」，间隔1天
• Automatic branch project triggering（自动分支项目触发）：自动构建的分支名称匹配规则：.*
  在Jenkins Enterprise的项目B下创建了相同类型的「GitHub Organization」项目，除项目A专属配置替换为项目B对应配置外，其余参数完全一致。

问题定位：缺失的配置项是什么？ #

项目B的GitHub PR无法触发continuous-integration/jenkins/pr-merge检查，GitHub和Jenkins管理员均未定位到问题。

更新补充 #

已经确认提交PR时项目B的Jenkins代理确实会启动构建，问题在于GitHub的PR页面没有展示continuous-integration/jenkins/pr-merge检查。需要展示该检查，才能在构建失败时阻止PR合并，同时也能快速定位构建失败原因。 #

解决方案 #

该问题属于Jenkins构建正常触发但未向GitHub回传状态检查的典型场景，按优先级排查以下配置即可：

1. Jenkins访问GitHub的凭证权限不足
   项目A使用的专属凭证默认拥有项目A所在组织的repo:status读写权限，你为项目B配置的凭证大概率未向组织B授予状态上报权限。
   操作验证：

• 确认Jenkins绑定的GitHub token是否勾选了repo:status、repo_deployment、public_repo三个权限域
• 确认该token对项目B所在的组织B已完成授权，未被组织的SAML或权限拦截规则拦截

2. Jenkins流水线未包含状态上报逻辑
   项目A的Jenkinsfile中默认内置了githubNotify或setGitHubPullRequestStatus类步骤，会在构建开始、结束时主动向GitHub上报状态。如果项目B的Jenkinsfile没有复用该逻辑，就不会回传状态。
   操作验证：

• 对比项目A和项目B的Jenkinsfile内容，确认是否包含状态上报相关代码
• 检查Jenkins构建日志，搜索是否有Notifying GitHub、Set status on PR类的报错信息

3. Jenkins GitHub插件状态检查名称配置不匹配
   部分版本的CloudBees GitHub Integration插件需要显式配置状态检查的上下文名称为continuous-integration/jenkins/pr-merge，如果项目B的流水线默认上下文为其他值，也会导致GitHub识别不到对应的检查项。
   操作验证：

• 进入Jenkins项目B的配置页，找到「GitHub」-「Status checks」配置项，确认上下文名称填写为continuous-integration/jenkins/pr-merge
• 开启Jenkins插件的debug日志，查看状态上报时的上下文参数是否符合预期

4. 组织级配置拦截
   确认组织B是否开启了第三方应用访问限制，拦截了Jenkins上报状态的请求。webhook是GitHub主动发往Jenkins可正常触达，但Jenkins回发到GitHub的API请求可能被组织权限规则拦截。
   完成以上排查后重新提交一次PR，即可在GitHub状态检查列表中看到对应的continuous-integration/jenkins/pr-merge选项。

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