CI 里的 lint 门禁是什么
把静态检查放进 CI：PR 触发、工具版本固定、失败即阻断合并。本地钩子可以被跳过，CI 不可跳过，所以它是静态防线真正的兜底。门禁的价值取决于反馈速度——越快出结果，开发者越愿意在当轮就把问题修掉，而不是攒到后面统一处理。
基本信息
| 触发时机 | pull_request 事件，或推送到受保护分支 |
|---|---|
| 工具版本 | 在流水线里锁定版本，避免隔夜行为漂移 |
| 失败策略 | 检查失败即阻断合并，不设静默放行 |
| 常见组合 | lint 与测试并行，各自独立报告结果 |
典型使用场景
- PR 触发检查：改动一提交就有结论，不必等合并后才发现
- 与测试并行：两条流水线互不阻塞，总反馈时间取较长的那条
- 多语言仓库：按目录拆成多个 job，互不拖慢
- 大型仓库控制时长：开启缓存或只检查改动范围
- 结果可追溯：失败信息带文件名与行号，直接定位修改点
GitHub Actions 示例
GitHub Actions 示例
name: lint
on: [pull_request]
jobs:
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: "3.12"
- run: pip install -r requirements-dev.txt # 检查工具版本在依赖里锁定
- run: ruff check .门禁设计要点
| 要点 | 做法 | 原因 |
|---|---|---|
| 版本锁定 | 依赖清单里固定工具版本 | 避免升级后隔夜报错，结果不可复现 |
| 独立 job | lint 与测试并行执行 | 总时长取两者最大值，而不是相加 |
| 只跑改动 | 增量检查或按目录拆分 | 大仓库全量运行容易拖到十几分钟 |
| 失败即阻断 | 分支保护要求检查通过 | 否则门禁只是建议，问题会累积 |
CI lint 与本地钩子的分工：钩子提供即时反馈，CI 提供不可跳过的兜底，两者规则口径要一致。
缓存依赖与工具产物能显著缩短流水线时间，但缓存键要包含依赖清单，否则会命中过期结果。
把 lint 串在测试之后执行：反馈慢、浪费流水线时长，失败原因也容易被后续输出淹没。