很多团队以为sonarQube里显示质量门禁失败就会自动拦住合并，但实际是否能拦住，取决于两条链路是否同时打通：一是拉取请求或合并请求的分析结果能回写到代码平台，二是代码平台把这条状态检查设为合并前置条件。下面按排查顺序把关键点拆开，先让合并真正被门禁卡住，再把Quality Gate条件改到你需要的口径上。

　　一、sonarQube质量门禁没拦住合并怎么办

　　你看到的现象通常是两种：sonarQube里失败但平台仍可点合并；或者平台上看不到门禁状态，导致规则根本没触发。处理时先别急着改阈值，先把阻断链路确认清楚，否则改了条件也拦不住。

　　1、先确认当前版本是否支持拉取请求分析与分支分析

　　进入sonarQube右上角【Administration】→【Configuration】→【License Manager】查看许可与版本信息，很多与拉取请求相关的能力需要从Developer Edition起才具备。

　　2、确认拉取请求分析确实在跑而不是只跑主分支

　　打开目标项目，在分支与拉取请求的下拉入口里检查是否能看到本次拉取请求的记录与门禁结果；如果只分析主分支，代码平台侧就很难拿到可用于拦截的PR状态。

　　3、在代码平台把门禁状态设为合并前置条件

　　如果你用GitHub，在仓库【Settings】→【Branches】→【Branch protection rules】里编辑目标分支规则，勾选【Require status checks to pass before merging】，并把SonarQube回写的状态检查加入必选列表。

　　如果你用GitLab，在仓库【Settings】→【Merge requests】的Merge Checks里启用【Pipelines must succeed】，让门禁失败时流水线失败从而阻止合并。

　　如果你用Azure DevOps，在目标分支的Branch policy里新增状态检查，选择【SonarQube/quality gate】作为必须通过的检查项。

　　如果你用Bitbucket Server，在仓库【Repository settings】→【Code Insights】里新增Required report，并设置为必须通过，按官方要求使用对应report标识。

　　4、避免门禁失败但流水线仍显示成功

　　有些流水线只负责把扫描跑完，并没有等待门禁判定回传，导致CI显示成功从而不触发平台拦截；以GitLab为例，官方建议让扫描等待门禁状态并在失败时让流水线失败。

　　二、sonarQube Quality Gate条件在哪里改

　　改条件的入口在Quality Gates里，但能不能改取决于权限与是否解锁编辑。建议先把门禁条件拆成新代码与全量两类，再决定哪些用于PR拦截，哪些用于主分支长期治理。

　　1、确认你有编辑Quality Gate的权限

　　默认只有具备全局Administer Quality Gates权限的用户能改门禁；权限位置在【Administration】→【Security】→【Global Permissions】，也可以在某个Quality Gate页面单独授予管理权限。

　　2、进入Quality Gates并解锁编辑

　　在顶部导航进入【Quality Gates】，选择要修改的门禁；在Conditions区域先点【Unlock editing】，再点【Add Condition】新增条件，或点行末的编辑图标修改阈值，删除则用行末的删除图标。

　　3、优先把用于拦截合并的条件配置到新代码口径

　　拉取请求分析的门禁判定只会使用Quality Gate里适用于新代码指标的条件，如果你只配置了全量代码条件，可能出现主分支失败但PR门禁不失败的错觉。

　　4、把新的Quality Gate正确应用到项目

　　项目默认使用实例的默认门禁；如需项目单独使用某个门禁，进入项目后点【Project Settings】→【Quality Gate】，选择【Always use a specific Quality Gate】并【Save】。

　　三、sonarQube拉取请求状态与分支规则核对

　　当你已经把平台侧的合并前置条件打开，但仍出现可合并或不显示的情况，通常是状态没有回写成功或回写的名称与平台规则不匹配。这里用一套核对清单把问题缩到具体一环，避免反复试错。

　　1、核对平台里被要求的状态检查名称是否与当前流水线一致

　　如果你调整过CI任务名或改过分析步骤，平台的必选检查可能仍指向旧名称，表现为一直等待或错误放行；在分支保护或合并规则里把旧检查移除并加入当前实际产出的检查项。

　　2、核对项目级ALM集成是否已完成并能正常装饰拉取请求

　　确保sonarQube项目已按所用平台完成项目级集成配置，否则平台侧可能看不到门禁装饰信息，合并规则也就无法引用该状态。

　　3、核对目标分支是否先做过一次基线分析

　　拉取请求判定依赖与目标分支对比的差异口径，目标分支未先分析时，PR结果可能不完整或不可用，进而影响门禁装饰与拦截效果。

　　4、核对门禁失败与平台拦截的触发路径是否一致

　　GitHub更依赖必选状态检查，GitLab更依赖流水线是否失败，Azure DevOps依赖分支策略中的状态检查项；把拦截点固定在一种机制上，避免一边看sonarQube失败，另一边流水线仍成功。

　　总结

　　处理sonarQube门禁不拦合并时，先把拉取请求分析与平台合并前置条件这条链路打通，再去Quality Gates里按新代码口径调整条件并应用到项目；最后用状态名称、集成配置与目标分支基线三项核对，把“不显示”“不阻断”定位到具体环节后再修正，效率会高很多。