关键是要让门禁结果决定流水线成败：必须配置sonarqube token与jenkins服务器连通，pipeline中显式调用waitforqualitygate()并设超时，门禁规则聚焦新增代码（如新增漏洞>0、新代码覆盖率
要让质量门禁真正“阻断”不合格代码，关键不是跑完扫描，而是把门禁结果变成流水线成败的决定性条件——失败即终止，不给绕过机会。
确保 SonarQube 与 Jenkins 连通并授权
连通性是硬拦截的前提。Jenkins 拿不到真实分析结果，门禁就形同虚设。
- 在 SonarQube 界面（User > My Account > Security）生成专用 Token，命名如
jenkins-ci，权限至少勾选 Execute Analysis 和 Browse；管理员还需加 Administer Quality Gates - Jenkins 全局配置中添加 SonarQube Server：Manage Jenkins > Configure System > SonarQube servers，填入 URL（如
http://sonarqube:9000）和 Token - 若 Jenkins 运行在 Docker 容器内且 SonarQube 在宿主机，URL 必须用
http://host.docker.internal:9000，不能写localhost
在 Pipeline 中强制等待并响应门禁结果
只执行 sonar-scanner 或 mvn sonar:sonar 不够。必须显式调用 waitForQualityGate()，并让它决定流水线状态。
- 扫描阶段后立即跟
stage('Quality Gate')，内部包裹timeout（建议 10–15 分钟），防止因 SonarQube 响应慢导致流水线长期挂起 - 该步骤会轮询 SonarQube API；一旦门禁失败（例如新增漏洞 > 0），Jenkins 状态立刻变为
UNSTABLE或FAILURE，后续所有 stage（含 deploy、merge）自动跳过 - 示例片段：
stage('Quality Gate') {
steps {
timeout(time: 12, unit: 'MINUTES') {
waitForQualityGate()
}
}
}
配置聚焦“新增代码”的有效门禁规则
门禁规则若检查全量代码，历史问题会让新提交永远无法通过。必须专注开发者本次改动。
- 登录 SonarQube → Quality Gates > Create，新建门禁（如命名
CI-Blocker） - 至少设置三项阻断条件：
• Added bugs is greater than 0
• Added vulnerabilities is greater than 0
• New coverage on new code is less than 80% - 保存后，在具体项目页面 → Project Settings > Quality Gate 中手动绑定该门禁，确保每次分析都按此裁决
让拦截结果可见、可追溯、不可绕过
门禁失败必须暴露在开发者最常看的地方，且无法被人工跳过。
- 将 SonarQube 分析结果回传至 PR 页面（GitHub/GitLab 需开启相应 Webhook 或使用官方插件），失败时直接显示红叉+具体原因
- Jenkins 流水线需配置
when { expression { currentBuild.result == 'SUCCESS' } }控制后续 stage，避免靠人工判断是否继续 - 禁止在 Jenkins 脚本中使用
catchError或ignore吞掉waitForQualityGate()的失败信号
