想讨论一个大任务的ocr-review-code实践问题

[duringnone]

目前我们实操流程：

1. 流程：gitlab-ci-pipline执行ocr审查任务，通过MR-event触发（创建MR时，启动ci-任务）

1）完整业务流程：MR创建 => ci任务（自动化workflow，其中包括ocr扫描git-diff代码） => ocr的评论MR代码 => 上报MR和ai-review-comment收集

2）风险：完整ci流程15min耗时，80%任务10min内完成，ocr耗时占比60%左右，如果MR变更增大，则ci任务可能超时

2. 目前配置ocr，执行平均耗时6min左右;配置参数： --format json --audience agent --concurrency 16

3. MR大小：日常90%的需求都是小MR（变更文件50个文件以内，不超过100个文件变更，排除非核心逻辑文件，真实review的文件数大概30个左右）

4. 问题：还有10%的大需求，例如：某个新系统的V1版本功能，涉及到300个左右的文件变更，面对如此大的MR，似乎无法按照上述的工作workflow进行管理，官方/各位大佬有什么好的生产实践落地方案参考吗？

[Qiyuanqiii]

我感觉单纯继续提高 --concurrency 不能从根本上解决这个问题。它控制的是文件组并发，而 --timeout 是每个文件组的超时时间；默认 medium 会执行两轮审查，每组的超时上限会从 10 分钟延长到 15 分钟，所以即使把并发设为 16，也无法保证 300 文件的 MR 一定能在 15 分钟内完成。

我比较建议这样处理：

1. 先运行 ocr review --preview --format json，根据 reviewable_count 和实际增删行数判断审查工作量，不要只看 MR 的文件总数。
2. 大 MR 最好按组件拆分。如果确实无法拆分，可以把 OCR 移出主 CI 的 15 分钟关键路径，作为独立的合并前检查；或者按组件并行分片，最后再统一汇总并发布评论。
3. 后续有新提交时，可以采用完整性门控的增量审查。只有上一次 manifest.terminal_state == "complete"、所有评论都发布成功，并且 MR 基线、规则、模型和 OCR 版本都没有变化时，才审查 last_head..new_head；否则回退到全量审查。
4. 如果同一提交、同一审查范围因为时间或 token budget 中断，可以保存 session，然后通过 --resume 继续。完整审查结束前，建议不要发布部分结果。
5. 不要只根据退出码判断是否完成，因为部分覆盖也可能退出 0。建议以 manifest.terminal_state == "complete" 且 coverage.failed 为空作为成功条件。
6. GitLab 目前的 OCR_INCREMENTAL 只负责避免重复发布相同行范围的评论，并不会减少 LLM 实际审查的代码量。

补充：超时与恢复

如果使用的是 Linux GitLab Shell Runner，不建议直接依赖 job timeout 实现可恢复中断。OCR 当前只监听 os.Interrupt（SIGINT），而 Shell Runner 超时或取消时首先发送 SIGTERM，可能导致 manifest 还没有完整写入，后续无法使用 --resume。

可以在 job timeout 之前主动发送 SIGINT，并预留 2～3 分钟用于收尾和 artifact 上传，例如：

timeout --signal=INT --kill-after=2m 11m \
  ocr review ... > .ocr/ocr-result.json

同时建议配置 artifacts: when: always，确保中断后的结果和 session 能够被保存。其他 GitLab executor 的终止信号可能不同，需要根据实际 executor 再确认。

来源：OCR 信号处理源码、GitLab Shell Runner 终止行为。ocr-result.json