提交拉取请求后，流水线已经跑完，页面却没有SonarQube检查结果，这时要先分清两件事：分析有没有完成，结果有没有传回代码仓库。两处使用的配置和凭据并不相同。下面以SonarQube Server与GitHub Actions为例，说明配置过程和排查入口；菜单参照Server 10.8等版本，其他版本可按对应名称查找。

　　一、SonarQube如何配置拉取请求分析

　　SonarQube Server的拉取请求分析从Developer Edition起提供。配置前先确认所用版本支持该功能，再完成仓库绑定和流水线接入。

　　1、连接GitHub并绑定项目

　　①在GitHub账号或组织设置中进入【Developer settings】→【GitHub Apps】，创建供SonarQube使用的应用。

　　②在应用的【Permissions&events】中，按对应SonarQube版本文档设置仓库权限，检查【Checks】是否具备读写权限。

　　③点击【Install App】，将应用安装到目标组织或账号，并授权访问需要分析的仓库。

　　④返回SonarQube，进入【Administration】→【Configuration】→【General Settings】→【DevOps Platform Integrations】，选择GitHub，填写应用信息并保存。

　　⑤对已有项目，打开【Project Settings】→【General Settings】→【DevOps Platform Integration】，核对【Configuration name】和【Repository identifier】。

　　仓库标识应对应实际仓库路径。扫描上传到了正确的SonarQube项目，不代表该项目一定绑定了正确的GitHub仓库，迁移或复制项目后尤其容易遗漏这里。

　　2、让流水线执行拉取请求分析

　　①打开SonarQube项目的【Administration】→【Analysis Method】，按安装版本提供的引导接入GitHub Actions；若该版本使用其他分析引导入口，则从项目初始化页面进入。

　　②在GitHub仓库打开【Settings】→【Secrets and variables】→【Actions】，保存流水线所需的SonarQube地址和分析令牌。

　　③编辑工作流，配置拉取请求触发，并按项目语言加入构建、测试及SonarScanner分析步骤。

　　④检查代码检出设置，保留Git元数据，并确保目标分支在运行环境中可用。

　　⑤创建测试拉取请求，在【Actions】中打开对应任务，核对扫描日志中的项目标识和拉取请求信息。

　　支持的CI环境可以自动识别PR参数。需要手动传入时，sonar.pullrequest.key对应PR编号，sonar.pullrequest.branch对应源分支，sonar.pullrequest.base对应目标分支。手工配置会覆盖自动识别结果，不能把示例编号长期写死。

　　二、SonarQube拉取请求未显示质量门禁状态如何排查

　　先在SonarQube中找到这次PR，再去GitHub检查回传状态。沿着这条顺序排查，比较容易确定故障发生在哪一段。

　　1、确认流水线确实运行了扫描

　　①打开GitHub仓库【Actions】，选择本次PR对应的工作流。

　　②展开扫描步骤，检查是否被条件判断跳过，或在构建失败后没有执行。

　　③查看令牌、服务器地址及连接错误，确认扫描报告已经上传。

　　④对照本次PR的提交SHA，排除查看的是上一次运行。

　　来自Fork仓库的PR还要检查凭据是否可用。不要为了让扫描执行，就给不受信任的PR代码开放高权限密钥，应使用适合该贡献来源的受控流程。

　　2、查看服务端后台任务

　　①在SonarQube项目中打开【Project Settings】→【Background Tasks】。

　　②按时间找到对应任务，查看是否仍在排队、处理中或已经失败。

　　③对失败任务打开操作菜单，点击【Show Error Details】，阅读具体错误。

　　④必要时查看该任务的扫描上下文，核对PR参数和分析配置。

　　扫描日志显示EXECUTION SUCCESS，只说明扫描器阶段成功，服务端仍需处理上传报告。后台任务没有完成，项目页面和仓库检查结果都可能尚未更新。

　　3、检查结果是否进入了正确的PR

　　①打开SonarQube项目的分支与拉取请求下拉列表，选择对应PR。

　　②核对目标分支、最近分析时间和提交信息。

　　③如果只有普通分支结果，返回【Actions】日志，检查是否识别到PR事件。

　　④检查手动设置的PR编号、源分支和目标分支，修正后重新运行。

　　目标分支也应先完成分析。若CI只检出了不完整的仓库内容，或擅自改动了待分析代码，需要先恢复正确的检出流程，再判断质量门禁结果。

　　4、检查回传权限与仓库绑定

　　SonarQube中已有本次PR的门禁结论，GitHub仍未显示时，可以集中检查平台集成。

　　①返回【Project Settings】→【General Settings】→【DevOps Platform Integration】，核对配置和仓库标识。

　　②在GitHub应用设置中查看【Install App】，确认安装范围包含当前仓库。

　　③打开【Permissions&events】，核对【Checks】等所需权限；权限调整后，确认安装方已接受更新。

　　④检查SonarQube服务端访问GitHub API的网络、代理、证书及应用凭据。

　　⑤回到PR的【Checks】页查看结果，不要只在【Conversation】中寻找评论。

　　分析令牌负责让扫描器向SonarQube提交报告，GitHub App凭据负责平台交互。更换分析令牌，通常无法解决应用无权写入检查结果的问题。

　　三、SonarQube质量门禁显示后如何验证配置

　　状态出现后，还应确认它跟随最新提交更新。需要禁止未通过门禁的代码合并时，另行配置仓库合并规则。

　　1、用一次完整流程检查更新结果

　　①向测试PR推送新提交，在【Actions】中确认触发了新一轮分析。

　　②打开PR的【Checks】，核对检查对应最新提交，而非旧结果。

　　③点击检查详情，确认能够进入正确的SonarQube项目和PR。

　　④需要强制检查时，在GitHub仓库【Settings】中的【Rules】或【Branches】设置里，将实际生成的检查项配置为合并要求。

　　sonar.qualitygate.wait可用于让扫描步骤等待门禁结论，但不能代替PR状态回传配置。流水线任务成功、门禁通过和允许合并，也应分别验证。

　　总结

　　SonarQube把代码问题带到评审阶段，开发人员可以在修改尚未合并时查看结果、讨论处理方式。对评审者来说，检查详情能直接回到对应代码，比在流水线日志中翻找报告省事。配置稳定后，同一套检查也能随着每次提交重复执行，让团队更容易看到修改后的变化。希望本文能帮助大家接通分析与仓库页面之间的流程，遇到状态缺失时找到具体检查入口。有相关需求，欢迎与我们交流。