技能介绍

先回答什么问题

PR 代码通过 SonarQube scanner 后，团队仍然需要人工打开 Web 界面确认 New Code 的 Quality Gate 是否通过，并对照 coverage、code smells、bugs、vulnerabilities 和技术债务判断是否放行。CI 脚本缺少统一入口把当前分支的质量门结果和关键指标抽出来，导致 reviewer 看不到同一口径，流水线卡点也容易滞后。这个技能聚焦把查询与判定过程变成可重复的工程检查。

技能如何工作

它面向 SonarQube Web API，按项目查询 Quality Gate status，提取整体状态、conditions 和失败原因；随后读取 coverage 与技术债务相关指标，帮助判断当前代码不是只跑通编译，而是满足项目自己的质量规则。对于 CI 场景，它可以和 sonar-scanner CLI 衔接：扫描器完成分析后，由技能查询并消费结果；也可以通过 SonarQube ALM integration API 做 PR decoration，让代码评审界面直接呈现门禁结论。核心流程是：定位项目或分支 → 拉取质量门与指标 → 汇总失败项 → 输出适合 CI 或 reviewer 使用的判定依据。

适用边界

它依赖 SonarQube 已有扫描结果；不会替代 sonar-scanner 本身，也不会凭空修复质量问题。上游说明要求 Java 17 和 npm，Native Git 必须在 PATH 中可用。如果改动包含 UI，需要先在 sonarqube-webapp 仓库本地构建，再通过 WEBAPP_BUILD_PATH 构建 SonarQube。构建时可用 -x test 跳过测试，但生产使用前仍应确认测试通过。不同 SonarQube 版本的 API 字段、PR decoration 能力和分支模型可能不同，接入时应把版本差异纳入验证。