检查结果怎么进入审查
静态检查结果默认只躺在 CI 日志里，没人翻日志，告警就长期无人处理。把这一层接进代码托管平台后，问题会以两种形式出现：一是文件与行号级的注释，直接标在差异页的新增行上；二是可被平台解析的结构化报告，例如 SARIF 与 GitLab Code Quality JSON。审查者在同一页就能看到告警，不必切到构建页面找日志。
基本信息
| 输出形式 | 行内注释 / 检查摘要 / 合并请求评论 |
|---|---|
| 报告格式 | SARIF（多平台通用）、GitLab Code Quality JSON |
| 承载平台 | GitHub Actions、GitLab CI、Jenkins 加插件 |
| 策略 | 按严重度分级：error 阻断、warning 提示 |
典型使用场景
- 新提交只针对改动行报错：把告警收敛到本次改动范围，避免历史负债淹没新问题
- 安全扫描接入：依赖扫描与代码扫描产出 SARIF，直接在差异页定位到风险行
- 覆盖率门禁：把覆盖率变化以摘要回写，低于阈值时阻断合并
- 大仓分批治理：先只对改动目录开启阻断，稳定后再扩大范围
- 合规留档：报告作为构建产物归档，支撑审计与问题回溯
GitHub Actions 上报 SARIF
GitHub Actions 上报 SARIF
name: lint
on: [pull_request]
jobs:
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: pip install ruff && ruff check --output-format=sarif --output-file=results.sarif .
- uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: results.sarif # 上传后自动在差异页标注文件与行号报告与门禁的分工
| 能力 | 说明 | 生效时点 |
|---|---|---|
| 行内注释 | 精确到文件与行号，贴近改动上下文 | 推送后几分钟内 |
| 检查摘要 | 总体通过或失败与问题计数 | 合并请求页面顶部 |
| 结构化报告 | SARIF 或 JSON，可被平台聚合与历史对比 | 作为构建产物长期留存 |
| 阻断门禁 | 命令退出码非零，阻止合并 | 分支保护规则生效时 |
注释有数量上限：用工作流命令方式输出注释时，单步最多展示 10 条 warning 与 10 条 error，超出的不会出现在页面上。重要规则要单独成 job，或改用摘要与报告承载全量结果。
报告与门禁分开推进：先只出报告不阻断，观察一到两周真实噪声比，再把稳定且高频的规则升级为阻断。一上来全量阻断会逼出绕过行为，例如加豁免注释或直接关闭检查。