要让jenkins真正卡住不达标代码，关键在于用waitforqualitygate()强制拦截并使门禁失败即终止流水线，需确保sonarqube连通、配置专用token与服务器、设置聚焦新增代码的门禁规则，并将结果回传pr页面实现不可绕过。
要让 Jenkins 真正卡住不达标代码，关键不是“跑完扫描”，而是让质量门禁结果决定流水线成败——未通过就立即失败，不允许继续部署或合并。
确保 SonarQube 服务与 Jenkins 可靠连通
连通性是硬拦截的前提。很多团队门禁形同虚设，根源在于 Jenkins 根本没拿到真实扫描结果。
- 在 SonarQube Web 界面（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() 并设置超时，否则 Jenkins 默认认为“扫描完成即成功”。
- 扫描阶段后必须紧跟
waitForQualityGate()，且包裹在timeout块中（建议 10–15 分钟），避免因 SonarQube 响应延迟导致流水线挂起 - 该步骤会轮询 SonarQube API 获取分析结果，一旦门禁失败（如新增漏洞 > 0），Jenkins 流水线状态立刻变为 UNSTABLE 或 FAILURE，后续所有 stage（包括 deploy）自动跳过
- 示例关键片段：
stage('Quality Gate') {<br> steps {<br> timeout(time: 12, unit: 'MINUTES') {<br> waitForQualityGate()<br> }<br> }<br>}
配置真正生效的质量门禁规则
门禁规则必须聚焦“新增代码”，否则旧债会拖垮新提交——没人能为历史问题负责，但必须为自己的改动负责。
- 登录 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 中手动绑定该门禁，确保每次分析都按此裁决
让拦截结果可见、可追溯、不可绕过
开发者必须一眼看到失败原因，且无法手动点击“跳过”。否则门禁只是装饰。
- 在 Jenkins 构建日志末尾，
waitForQualityGate()会输出清晰结论，如Failed quality gate: Added vulnerabilities > 0 (was 2) - 结合 Git 集成（如 GitHub Checks 或 GitLab CI Status），将门禁结果直接回传 PR 页面，显示为红色 ❌，合并按钮置灰
- 禁用 Jenkins 的“跳过阶段”功能，避免人工干预绕过门禁；可在 Pipeline 中用
when { expression { ... } }进一步约束部署阶段只在门禁通过后触发
