技能介绍

它解决什么问题

CI 里跑完 SonarQube 扫描只是第一步，真正的问题是：扫描结束后质量门禁是 PASSED 还是 FAILED？失败的原因到底是覆盖率不够、新出现的 bug，还是严重的告警？大型项目还经常混用多种语言，Java 部分看 JaCoCo、前端看 Istanbul、其他服务看 lcov，报告格式不统一，人肉逐个看 SonarQube Report 既慢又容易漏。

这个代理要做的就是把这些判断交给自动化：持续查询 SonarQube 的 Web API 拿到门禁状态，解析 JaCoCo、Istanbul 和 lcov 格式的覆盖率报告，并按设定的阈值决定是否放行。

它如何工作

核心能力集中在两件事上：

门禁监控：通过 SonarQube Web API 查询质量门禁结果，而不是解析终端里容易被截断的构建日志。
阈值执行：将项目配置的代码质量阈值与实际指标比对，结果明确告诉上层流程能不能合入或发布。

具体使用时的关键步骤是：

构建流程跑完扫描，任务里保留 SonarQube 的项目键和服务器地址。
代理调用 Web API 拉取最新的门禁状态。
对多语言项目分别解析覆盖率产物，包括 JaCoCo、Istanbul 和 lcov。
把阈值检查的结果和覆盖率数值输出为结构化结果，交给 CI 决定后续动作。

这套逻辑适合 CI 流水线、PR 检查或发布前的自动把关。开发者可以继续关注门槛本身，代理负责把多来源的报告整理成统一结论。

适用边界与注意点

它只做门禁状态监控和阈值判定，不能替代 SonarQube 服务器本身的分析能力。
上游环境要求 Native Git 必须可用并在 PATH 中。
从源码构建时需要 Java 17 和 npm；如果只想构建而不跑测试，可以通过 Gradle 命令加 -x test 跳过测试。
如果改动包含 UI 部分，需要先 clone sonarqube-webapp 仓库，在本地构建，再通过 WEBAPP_BUILD_PATH 环境变量构建主仓库。
阈值具体数值、扫描执行和 CI 集成方式仍由项目侧配置，代理不改变这些流程的语义。