open-code-review CI 流水线报 Failed to parse OCR output 怎么排查【免费下载链接】open-code-reviewFast, efficient, battle-tested at Alibabas scale. Hybrid architecture code review tool: deterministic pipelines LLM Agent, precise line-level comments, built-in multi-language ruleset (NPE, thread-safety, XSS, SQL injection), OpenAI Anthropic compatible.项目地址: https://gitcode.com/GitHub_Trending/op/open-code-review在 GitHub Actions 或 GitLab CI 中运行 open-code-reviewocr的审查流水线时评论区或 workflow 日志里出现Failed to parse OCR output说明审查脚本没能把ocr review --format json的输出解析成 JSON。这篇文章给出文档中记录的排查路径先区分是ocr review本身退出失败还是输出不是合法 JSON然后复查 LLM 凭据最后通过 stderr 日志定位根本错误。先搞清楚这个报错是谁打出来的CI 配方都按同一个模式工作ocr review --from ... --to ... --format json --audience agent把 JSON 信封写入结果文件随后的脚本GitHub Actions 的 post-review-comments.js、GitLab 的 post_review.py读取并解析这份文件。解析失败时脚本才打印Failed to parse OCR output所以报错点在解析 OCR 输出这一步而不是解析逻辑本身坏了。两种典型情况ocr review以非零码退出GitHub Actions 配方会直接用该退出码让 job 失败评论发布步骤被跳过退出码为 0 但 stdout 不是合法 JSON解析错误会以 summary 报错的形式出现在 PR/MR 上。post-review-comments.js 中的实际逻辑是JSON.parse失败时记录Failed to parse OCR output: ${e.message}随后读取 stderr 日志的尾部把错误内容包成⚠️ **OpenCodeReview** encountered an error:的 summary 评论发到 PR 上因为输出解析失败manifest 不存在不会推进 checkpoint。第一步复查 LLM 凭据文档给出的首要原因是OCR_LLM_URL或OCR_LLM_AUTH_TOKEN缺失或错误。按你的 CI 平台到对应位置复查GitHub Actions在Settings → Secrets and variables → Actions下检查这两个 secret。GitLab CI在Settings → CI/CD → Variables下检查这两个变量。OCR_LLM_AUTH_TOKEN应勾选 Masked。这两个值的语义见 CI 集成文档变量必填说明OCR_LLM_URL是LLM API endpoint例如https://api.openai.com/v1/chat/completions。OCR_LLM_AUTH_TOKEN是LLM API 认证 token会被传给ocr config set llm.auth_token。注意 OCR 自身的直接环境变量是OCR_LLM_TOKEN不是OCR_LLM_AUTH_TOKEN——这两个名字容易混淆。OCR_LLM_MODEL否模型名没有默认值必须显式设置。CI 里 runner 是临时的不存在可回退的~/.opencodereview配置所以凭据错误会直接让ocr review跑不出合法 JSON。第二步看 stderr 日志找根本错误凭据确认无误后按平台查看原始 stderrGitHub Actions在 Run OpenCodeReview 步骤日志里JSON 结果和 stderr 都会打印当upload_artifacts: true默认原始ocr-result.json和ocr-stderr.log会上传为名为ocr-review-result-run_id-run_attempt的 workflow artifact从该次运行的Artifacts区域下载查看步骤还暴露comments_total、comments_inline、comments_skipped、comments_failed、summary_comment_url输出可在 job 的 step outputs 中检查。GitLab CI上游 pipeline 把原始审查 JSON 写到.ocr/ocr-result.json、stderr 写到.ocr/ocr-stderr.log两者都在 artifacts 中上传when: always、保留 1 周并加一个调试步骤即可查看script: - cat .ocr/ocr-result.json - cat .ocr/ocr-stderr.log文档的 CI 页面给出的等效写法是cat /tmp/ocr-result.json和cat /tmp/ocr-stderr.log以实际 pipeline 文件写出的路径为准见 examples/gitlab_ci/.gitlab-ci.yml。如果 stderr 为空且 JSON 文件是空的通常回到第一步重新核对凭据stderr 里记录的才是导致本次运行失败的具体错误。顺带排除两个相邻症状排查时容易混淆的两条相关记录同样来自 CI 文档的 Troubleshooting 表Cannot find merge-basecheckout 用了浅克隆而 range 模式审查需要完整历史。GitHub 上游 workflow 在actions/checkout上设置了fetch-depth: 0GitLab pipeline 设置了GIT_DEPTH: 0——如果你改过这两个文件保留该设置。OCR_DEBUG不生效该环境变量目前在 OCR 中尚未实现设置OCR_DEBUG: 1没有任何效果。要看详细输出就检查上面提到的 raw JSON 与 stderr 文件或在本地跑ocr review。验证修复凭据或配置修正后重新触发流水线成功条件是ocr review退出码为 0、.ocr/ocr-result.json或 artifact 中的ocr-result.json能被解析PR/MR 上出现✅/ OpenCodeReview的 summary 评论和行内评论而不再是Failed to parse OCR output的报错 banner。参考文档GitHub Actions 集成含 GitHub / GitLab 两张 Troubleshooting 表、examples/github_actions/README.md 与 examples/gitlab_ci/README.md 的 Troubleshooting / Debugging 章节。【免费下载链接】open-code-reviewFast, efficient, battle-tested at Alibabas scale. Hybrid architecture code review tool: deterministic pipelines LLM Agent, precise line-level comments, built-in multi-language ruleset (NPE, thread-safety, XSS, SQL injection), OpenAI Anthropic compatible.项目地址: https://gitcode.com/GitHub_Trending/op/open-code-review创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考