OpenCodeReview CI/CD 集成实战指南GitHub Actions 与 GitLab CI 流水线从零配置到深度定制【免费下载链接】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本文以开源仓库 open-code-review 的官方 CI 文档为主线系统讲解如何把 AI 代码评审工具 OpenCodeReview下文简称 OCR接入 GitHub Actions 与 GitLab CI从事件触发、runner 内安装与 LLM 配置、分支区间评审到解析 JSON 外壳、回贴内联评论的完整链路。读完本文你将能独立复制上游现成流水线、正确配置两类凭据、用 action/变量调优评审强度与并发并掌握--background、--rule、SARIF 上传、自定义 bot 身份等进阶定制能力。CI/CD 集成如何工作上游仓库在 examples/github_actions/ocr-review.yml 与 examples/gitlab_ci/.gitlab-ci.yml 各提供一条现成流水线。两者都是 CLI 参考中核心命令ocr review的薄包装遵循完全相同的六步模式在 PR / MR 事件上触发。新建 pull request、更新的 merge request或手动/open-code-review评论触发作业。在 runner 中安装ocr通常是npm install -g alibaba-group/open-code-review。runner 是临时的因此每次运行都重新安装。从 CI secret 经ocr config set配置 LLM端点、token、model。CI 环境没有持久化的~/.opencodereview可回退所以配置全部发生在作业内。以区间模式运行评审输出机器可读使 stdout 是干净的 JSON 外壳ocr review \ --from origin/base-branch \ --to origin/head-branch \ --format json \ --audience agent--format json给出可解析载荷--audience agent屏蔽进度行进度转到 stderr不污染 stdout 的 JSON。解析 JSON并遍历comments[]。通过 provider 的 review API 把评论回贴到 PR / MR。无有效行信息的条目文件级发现合并到摘要备注而非内联张贴若内联批量 API 拒绝请求张贴步骤也回退为普通摘要评论。始终涉及两类凭据OCR 用来生成发现的LLM 凭据端点 token model以及张贴步骤用来回贴评论的PR/MR 写 token。GitHub 配方通过GITHUB_TOKEN自动提供后者GitLab 建议显式配置GITLAB_API_TOKEN但对 fork MR 会回退使用内置CI_JOB_TOKEN它可通过/discussions发起讨论——为可靠性推荐使用专用 token。从源码看--format json与--audience agent的配合在 cmd/opencodereview/review_cmd.go 的用法示例中两者正是作为机器消费的标准组合出现。--audience agent把人类可读的进度行路由到 stderr确保管道下游解析 stdout 时不会遇到夹带的日志文本——这也是后续所有张贴脚本能稳定工作的前提。GitHub Actions它做什么上游工作流位于 examples/github_actions/ocr-review.yml在pull_request_targetopened、synchronize、reopened和issue_comment事件上触发后者正文以/open-code-review或open-code-review开头——让评审者通过在 PR 上评论按需重跑 OCR。用pull_request_target而非pull_request使即便从 fork 提交的 PR 也能用上 secretOCR 只读 diff不执行 PR 中的代码因此是安全的。通过npm install -g alibaba-group/open-code-review安装 OCR用ocr config set写配置再以分支区间模式运行核心命令--from merge-base --to head --format json。解析 JSON 外壳并通过 GitHub Pull Request Review API 把每条发现作为内联评审评论张贴。无行信息的评论合并到摘要正文。若批量提交失败回退为逐条张贴并在摘要评论中呈现统计。工作流里值得注意的一个实现细节是条件并发组concurrency.group中匹配的评审事件PR 事件 /open-code-review评论共享ocr-pr_number组并启用cancel-in-progress: true新评审会取消同一 PR 上过期的旧评审而不匹配的普通对话评论落入唯一的noop-run_id组立即跳过且不会打断正在运行的评审。GitHub Actions 会在 job 级if之前评估并发组若不这样设计任何普通评论都可能误杀运行中的评审。安装把工作流放进你的仓库也可直接拷贝仓库内文件mkdir -p .github/workflows curl -o .github/workflows/ocr-review.yml \ https://raw.githubusercontent.com/alibaba/open-code-review/main/examples/github_actions/ocr-review.yml必需 secret在Settings → Secrets and variables → Actions下设置Secret必需说明OCR_LLM_URL是LLM API 端点如https://api.openai.com/v1/chat/completions。OCR_LLM_AUTH_TOKEN是LLM API 的认证 token。此 CI secret 传给ocr config set llm.auth_token。OCR 的直接环境变量是OCR_LLM_TOKEN不是OCR_LLM_AUTH_TOKEN。OCR_LLM_MODEL否模型名。无默认——必须显式设置。OCR_LLM_USE_ANTHROPIC否Anthropic Claude 模型设为true。GITHUB_TOKEN自动提供工作流声明pull-requests: write以便张贴评审评论。注意OCR_LLM_MODEL与OCR_LLM_USE_ANTHROPIC在示例中作为variablesvars.使用而非 secretssecrets.因为后者与前者一样由工作流映射为 action input。工作流启动时还会运行ocr config set llm.extra_body {thinking: {type: disabled}}为不支持该字段的 LLM provider 关闭 thinking-mode 请求。若你的 provider 需保留 thinking-mode删除该行或在llm_extra_bodyinput 中覆盖。Action 参数上游工作流通过uses: alibaba/open-code-reviewmain把评审委托给可复用的 composite actionaction.yml。除上述凭据外以下 input 用于调节评审本身——在 action 步骤的with:下传入Input默认值说明effort传给ocr review --effort的评审强度预设low、medium或high不区分大小写。留空则沿用 CLI 默认值已配置的值否则为 medium。需要 OCR v1.10.0 或更新版本在更旧版本上 action 会提前以明确报错失败。max_tokens_budget传给ocr review --max-tokens-budget的 token 总量上限输入 输出。留空或0表示不限。超过上限后停止派发被跳过的文件记为failed(budget)已产生的部分结果仍会发布评审以 0 退出。llm_reasoning_effort面向支持reasoning_effort请求字段的模型如 GLM-5.x、OpenAI reasoning 模型的推理深度minimal、low、medium、high、max不区分大小写。经llm_extra_body合并进请求体因此所有已发布的 CLI 版本均可使用llm_extra_body中显式的reasoning_effort键优先于此 input。留空默认则不发送。仅适用于 OpenAI 兼容协议——Anthropic API 会拒绝未知请求体字段action 在该协议下会快速失败Anthropic 的 thinking 控制请改用llm_extra_body中的显式键。stream_progressfalse设为true时把[ocr]实时进度行流入工作流日志stderr 上的 human audience而不是在评审结束前保持静默。仅影响展示stderr 仍会写入文件供产物上传与评论张贴使用。- uses: alibaba/open-code-reviewmain with: llm_url: ${{ secrets.OCR_LLM_URL }} llm_auth_token: ${{ secrets.OCR_LLM_AUTH_TOKEN }} llm_model: ${{ vars.OCR_LLM_MODEL }} llm_use_anthropic: ${{ vars.OCR_LLM_USE_ANTHROPIC }} effort: high max_tokens_budget: 10000000 llm_reasoning_effort: low stream_progress: true完整 input 列表见 action.yml——包括张贴模式与跨 push 检查点等高级能力摘录如下Input默认值说明sticky_summarytrue摘要维度为true时原地更新已有摘要评论sticky而非每次运行张贴新评论。incrementalfalse增量维度为true时只追加(path, line range)与既有 bot 评审评论不重叠的内联评论。历史永不删除非破坏性。incremental_overlap_threshold0.6增量模式判断两条多行评论是否重叠的 IoU 阈值。两行单行评论同行即匹配单行 vs 多行永不匹配。checkpoint_rangefalse跨 push 检查点为true时一次完整完成选定范围的运行会在 sticky 摘要中记录其覆盖的 head下次运行只评审checkpoint..new head而非merge-base..new head。要求sticky_summary: true。full_reviewfalse即使启用checkpoint_range也强制一次完整评审reasonmanual_full_review。运行仍会记录新检查点。review_task_timeout15单文件/并发任务超时分钟1–120传给ocr review --timeout不是整次评审的墙钟上限。llm_timeout300每个模型请求的 LLM HTTP 超时秒。llm_extra_body{thinking: {type: disabled}}追加到 LLM 请求体的 JSON无对应环境变量经ocr config set llm.extra_body写入。ocr_versionlatestalibaba-group/open-code-review的 npm 版本规格要求 v1.9.6 或更新action 会在旧版本上提前失败。review_concurrency—传给ocr review --concurrency的值。background—传给ocr review --background的上下文。rule—传给ocr review --rule的自定义规则 JSON 路径。upload_artifactstrue把原始 JSON 结果与 stderr 上传为工作流产物必须传字符串true/false未加引号的 YAML 布尔不会匹配。route_severity_below把 severity 等于或低于该级别的发现从内联评论路由到 PR 摘要fail-open绝不丢弃发现。route_categories逗号分隔的类别列表从内联路由到摘要bug、security、performance、maintainability、test、style、documentation、other。review_comment_batch_size50单次createReview调用打包的内联评论数上限。checkpoint_range的 fail-closed 设计从 action.yml 的 Resolve review range 步骤可以看出只有当摘要评论存在且由本 token 发布、标记可读、base 未移动、配置指纹含llm_url、llm_model、effort、max_tokens_budget、rule内容、OCR 实际版本等十余个轴未变化、且git merge-base --is-ancestor能证明检查点是新 head 的祖先时才会收窄评审范围任何一环存疑都回退为完整范围评审并在range_summary/range_reason输出中说明原因如config_changed、base_changed、not_ancestor、unknown_object。规则文件按内容做 SHA-256 指纹——包括仓库自身的.opencodereview/rule.json——因此编辑规则一定会使旧检查点失效。定制以下都是对你刚复制的工作流文件.github/workflows/ocr-review.yml的编辑。背景上下文--background是效果最显著的单一参数——见适用于所有模式的提示。传入 PR 标题当标题遵循feat(auth): add OAuth2 support这样的语义约定时效果更好- name: Run OCR review env: PR_TITLE: ${{ github.event.pull_request.title }} BASE_REF: ${{ github.base_ref }} HEAD_REF: ${{ github.head_ref }} run: | ocr review \ --background $PR_TITLE \ --from origin/$BASE_REF \ --to origin/$HEAD_REF \ --format json --audience agent把 PR 可控的值通过env:传入不要把${{ }}直接插值进run:。GitHub 在 shell 解析该行之前就已把${{ }}做了文本替换因此包含 shell 元字符的 PR 标题或分支名会在你的 runner 上被执行注入攻击风险。自定义规则用--rule传入项目专属规则文件- name: Run OCR review env: BASE_REF: ${{ github.base_ref }} HEAD_REF: ${{ github.head_ref }} run: | ocr review --rule ./my-rules.json \ --from origin/$BASE_REF \ --to origin/$HEAD_REFschema 见评审规则。安全提示不要在 secret 生效范围内把rule指向来自 PR 分支的文件应使用 base 分支上的可信规则文件。并发默认 8 个并行子 agent——每个文件组一个。大 PR 上调低以免触发 LLM provider 速率限制- name: Run OCR review env: BASE_REF: ${{ github.base_ref }} HEAD_REF: ${{ github.head_ref }} run: | ocr review --concurrency 5 \ --from origin/$BASE_REF \ --to origin/$HEAD_REF触发模式默认工作流在 PRopened时以及以/open-code-review或open-code-review开头的 PR 评论时触发。两种常见调整在更多 PR 生命周期事件上运行如推送新 commit 时复审on: pull_request: types: [opened, synchronize, reopened, ready_for_review]使用不同评论关键字if: | github.event_name pull_request || (github.event_name issue_comment github.event.issue.pull_request startsWith(github.event.comment.body, /review))github.event.issue.pull_request检查确保评论在 PR 上而非普通 issue 上。上游示例工作流examples/github_actions/ocr-review.yml还额外加了github.event.comment.user.type ! Bot防止 PAT/App token 造成的自触发循环与author_association白名单MEMBER/OWNER/COLLABORATOR防止任意评论者消耗 LLM 配额两道防线若你修改了if中的关键字务必同步修改concurrency.group中的同一谓词。固定 OCR 版本默认工作流安装最新发布版本。固定- name: Install OpenCodeReview run: npm install -g alibaba-group/open-code-review1.0.0若使用 composite action则同时固定 action 引用与ocr_versioninput 两个坐标仅固定 action 引用不会冻结评审行为因为 CLI 仍按latest安装。以 GitHub App 身份发布默认评审评论来自github-actions[bot]。要以OpenCodeReview Bot这类自定义品牌的 bot 发布把GITHUB_TOKEN换成 GitHub App installation token。在Settings → Developer settings → GitHub Apps → New GitHub App创建 app。禁用 webhook此用例不需要。在Repository permissions授予Pull requestsRead and writeContentsRead-only用于取 diffMetadataRead-only必需从 app 设置页生成私钥并下载.pem文件。记下同页的App ID。把 app安装到你想 OCR 评审的仓库。Installation ID 出现在安装后 URL 中如https://github.com/settings/installations/12345→ ID 为12345。在Settings → Secrets and variables → Actions下添加三个 secretSecret值GITHUB_APP_IDApp ID。GITHUB_APP_PRIVATE_KEY.pem文件全部内容含-----BEGIN RSA PRIVATE KEY-----与-----END RSA PRIVATE KEY-----行。GITHUB_APP_INSTALLATION_IDInstallation ID。在评论张贴步骤中生成并使用 token- name: Get GitHub App Token id: app-token uses: actions/create-github-app-tokenv1 with: app-id: ${{ secrets.GITHUB_APP_ID }} private-key: ${{ secrets.GITHUB_APP_PRIVATE_KEY }} - name: Post review comments to PR uses: actions/github-scriptv7 with: github-token: ${{ steps.app-token.outputs.token }} script: | # ...existing post script...评审现在会以你 app 的名字而非github-actions[bot]发布。将发现上传到 GitHub Code ScanningSARIF--format sarif会把 SARIF 2.1.0 报告写入 stdout。把它重定向到文件并用 CodeQL 的upload-sarifaction 上传让发现出现在Security → Code scanning下- name: Run OCR review env: BASE_REF: ${{ github.base_ref }} HEAD_REF: ${{ github.head_ref }} run: | ocr review \ --from origin/$BASE_REF \ --to origin/$HEAD_REF \ --format sarif --audience agent results.sarif - uses: github/codeql-action/upload-sarifv3 with: sarif_file: results.sarifSARIF 是机器可读格式因此 OCR 会在 stdout 上抑制进度行results.sarif只包含报告本身。--preview不支持--format sarif——请运行完整的 review或ocr scan来生成报告。关于 SARIF 字段的具体渲染可对照 cmd/opencodereview/sarif.go 及其测试 sarif_test.go 查看实现。故障排查症状原因 / 修复Cannot find merge-basecheckout 步骤用了浅克隆但区间模式评审需要完整历史。上游工作流在actions/checkout上设fetch-depth: 0——编辑文件时保留该设置。Failed to parse OCR outputOCR_LLM_URL或OCR_LLM_AUTH_TOKEN缺失或错误。在Settings → Secrets and variables → Actions下复查值。评审评论落到错误行通常意味着评审开始到评论张贴之间 diff 发生了偏移。张贴脚本此时回退为普通 issue 评论——无需处理。注意。OCR_DEBUG环境变量目前在 OCR 中未实现——设置OCR_DEBUG: 1无效。此处记录以备将来接入。当前若需详细输出可检查工作流写到/tmp/ocr-result.json和/tmp/ocr-stderr.log的原始评审 JSON 和 stderr见下方故障排查或本地运行ocr review。使用 composite action 时默认会把这两个文件上传为ocr-review-result-run_id-run_attempt产物。GitLab CI上游流水线位于 examples/gitlab_ci/.gitlab-ci.yml。它做什么在merge_requests事件上触发所有 MR 事件——创建、更新、重开。在node:20镜像中运行安装 OCR通过ocr config set配置再以 MR diff 模式运行核心命令。用内联 Python 脚本解析 JSON 外壳把每条发现作为 GitLab Discussion在 diff 上内联张贴用 MR 的versions端点计算正确的base_sha/start_sha/head_sha以精确定位。对无法内联张贴的评论回退为普通 MR note并以摘要 note 收尾。上游流水线还做了几件值得注意的事examples/gitlab_ci/.gitlab-ci.yml声明GIT_DEPTH: 0强制完整克隆区间评审需要 merge-base用resource_group: mr-review-$CI_MERGE_REQUEST_IID与interruptible: true防止同一 MR 的旧流水线继续运行--to使用CI_COMMIT_SHA而非源分支名以兼容 fork MR 的 commit 解析产物路径放在项目内的.ocr/目录GitLab Runner 拒绝上传 build 目录之外的路径并通过 dotenv 报告向后续 stage 暴露统计量。安装把流水线放进仓库根注意.gitlab-ci.yml与post_review.py要一起拷贝脚本路径相对于流水线文件位置curl -o .gitlab-ci.yml \ https://raw.githubusercontent.com/alibaba/open-code-review/main/examples/gitlab_ci/.gitlab-ci.yml若已有.gitlab-ci.yml并想保留把配方放到其他路径并用include:引入include: - local: ci/ocr-review.gitlab-ci.yml必需 CI/CD 变量在Settings → CI/CD → Variables下设置变量必需掩码说明OCR_LLM_URL是否LLM API 端点 URL。OCR_LLM_AUTH_TOKEN是是API 认证 token。此 CI 变量传给ocr config set llm.auth_token。OCR 的直接环境变量是OCR_LLM_TOKEN不是OCR_LLM_AUTH_TOKEN。OCR_LLM_MODEL否否模型名。无默认——必须显式设置。GITLAB_API_TOKEN否是带apiscope 的 project / personal / group access token。可选——缺失时回退使用内置CI_JOB_TOKEN如对 fork MR。为可靠性推荐专用GITLAB_API_TOKEN。GitLab 拒绝短于 8 字符的变量因此流水线中llm.use_anthropic硬编码为false。要用 Anthropic Claude 模型直接编辑脚本。流水线启动时还会运行ocr config set llm.extra_body {thinking: {type: disabled}}为不支持该字段的 LLM provider 关闭 thinking-mode 请求。若你的 provider 需保留 thinking-mode删除该行。快速 bot 命名提示。对 Project Access Token 和 Group Access Tokentoken 的名字会出现在 MR 讨论旁。把 token 命名为OpenCodeReview Bot即可让评审讨论带上品牌名无需额外设置——当你不需要下文以服务账号身份发布中记录的更持久服务账号设置时很方便。流水线还支持一批可选变量用于微调评审行为来自 examples/gitlab_ci/.gitlab-ci.yml 头部注释OCR_REVIEW_CONCURRENCY--concurrency默认 8、OCR_BACKGROUND--background如 MR 标题、OCR_RULE--rule、OCR_VERSIONnpm 版本规格默认latest固定如1.8.8或~1.8可获得可复现评审、OCR_LANGUAGE评审输出语言、OCR_LLM_AUTH_HEADER自定义认证头名、OCR_LLM_EXTRA_HEADERSKV,KV形式的额外头、OCR_LLM_TIMEOUTOCR 原生从环境变量读取无需ocr config set。定制以下都是对你刚复制的.gitlab-ci.yml的编辑。背景上下文把 MR 标题传给--background——当标题遵循feat(auth): add OAuth2 support这样的语义约定时效果更好script: - | ocr review \ --background $CI_MERGE_REQUEST_TITLE \ --from origin/$CI_MERGE_REQUEST_TARGET_BRANCH_NAME \ --to ${CI_COMMIT_SHA} \ --format json --audience agent自定义规则与并发与 GitHub Actions 配方相同的参数——--rule传项目专属规则文件--concurrency限制并行子 agent默认 8每个文件组一个script: - | ocr review --rule ./my-rules.json --concurrency 5 \ --from origin/$CI_MERGE_REQUEST_TARGET_BRANCH_NAME \ --to ${CI_COMMIT_SHA}规则 schema 见评审规则。固定 OCR 版本script: - npm install -g alibaba-group/open-code-review1.0.0避免每次推送都复审only: [merge_requests]在每次MR 更新时触发对长生命周期 MR 会消耗大量 LLM token。GitLab 无原生仅在创建时事件因此推荐模式是运行评审前检测已有 OCR note若有则跳过。把ocr review调用替换为 Python wrapperimport json, os, sys, urllib.request GITLAB_URL os.environ.get(CI_SERVER_URL, https://gitlab.com) PROJECT_ID os.environ[CI_PROJECT_ID] MR_IID os.environ[CI_MERGE_REQUEST_IID] API_TOKEN os.environ[GITLAB_API_TOKEN] url ( f{GITLAB_URL}/api/v4/projects/{PROJECT_ID} f/merge_requests/{MR_IID}/notes?per_page100 ) req urllib.request.Request(url, headers{PRIVATE-TOKEN: API_TOKEN}) with urllib.request.urlopen(req) as resp: notes json.loads(resp.read().decode()) if any(OpenCodeReview in n.get(body, ) for n in notes): print(OCR already reviewed this MR. Skipping to save tokens.) sys.exit(0) # ...otherwise call ocr review ... as usual and write the JSON to # the file the posting step expects.要在此之后强制复审从 MR 删除之前的 OCR note——下次流水线运行会看不到 OCR note便会继续。自托管 GitLab无需改代码。张贴脚本读CI_SERVER_URLGitLab 在每个 runner 上自动设置因此开箱即可与你自己的实例通信。只需确保GITLAB_API_TOKEN由你的自托管实例签发而非gitlab.com。以服务账号身份发布默认评审讨论出现在GITLAB_API_TOKEN所属用户名下。改用项目级服务账号即可获得OpenCodeReview Bot这类自定义品牌的 bot 身份。在Project → Settings → Service Accounts → New service account创建服务账号。你选的名字如OpenCodeReview Bot会出现在 MR 讨论旁。在Settings → Members → Invite member邀请它到项目。搜索服务账号名并分配Developer或Maintainer——两者都有张贴讨论所需权限。在Settings → Service Accounts →该账号→ Add new token签发 access token。所需 scopeapi。立即复制 token——GitLab 只显示一次。在Settings → CI/CD → Variables替换 token 值——用服务账号的 token 替换现有GITLAB_API_TOKEN值变量名保持不变。讨论现在以服务账号名而非最初创建 token 的用户名发布。故障排查症状原因 / 修复Cannot find merge-baserunner 用了浅克隆。上游流水线设GIT_DEPTH: 0强制完整克隆——编辑文件时保留该设置。张贴时API error 403GITLAB_API_TOKEN缺apiscope、不是项目成员或——自托管时——由不同实例签发。以apiscope 重签并在Settings → CI/CD → Variables下重新添加。Failed to parse OCR outputOCR_LLM_URL或OCR_LLM_AUTH_TOKEN错误。在Settings → CI/CD → Variables下复查值。内联评论落到错误行GitLab 内联讨论要求精确 SHA 匹配张贴脚本取versions元数据以得到正确的base_sha/start_sha/head_sha。若某条发现仍无法锚定回退为普通 MR note。流水线把原始评审 JSON 写到/tmp/ocr-result.jsonstderr 写到/tmp/ocr-stderr.log。可在 debug 步骤中 cat 它们检查 OCR 返回了什么script: - cat /tmp/ocr-result.json - cat /tmp/ocr-stderr.log从源码看张贴脚本的健壮性设计GitLab 配方的核心 examples/gitlab_ci/post_review.py 与 GitHub Action 的张贴模块 scripts/github-actions/post-review-comments.js 保持行为对齐——每条内联评论带[category · severity]徽章张贴前按path → start_line → end_line → 原始索引确定性排序每次内联讨论内嵌不可见的 HTML id 标签!-- ocr-... --5xx/超时重试前先查询该 id 是否已落库实现幂等去重对 400 位置解析失败脚本会拉取 MR diff 清单把发现分类为 valid/invalid/unknown证明在 diff 之外的发现降级进摘要而非盲目重试增量模式用 IoU 阈值默认 0.6判断多行评论是否与历史 bot 讨论重叠。脚本只依赖标准库json、urllib任何标准 python3 镜像开箱即用且配套 post_review_test.py 单元测试覆盖了上述全部行为。另见CLI 参考——两条流水线消费的 JSON 结构含comments[]与 manifest 字段从头写 CI 脚本时有用配置文档见configuration。评审规则——自定义规则文件 schema--rule的完整字段说明。其他平台集成可参考 examples 下的 bitbucket_pipelines、codeup_ci、gerrit_ci、gitflic_ci 等同类配方。【免费下载链接】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），仅供参考 OpenCodeReview CI/CD 集成实战指南：GitHub Actions 与 GitLab CI 流水线从零配置到深度定制
OpenCodeReview CI/CD 集成实战指南GitHub Actions 与 GitLab CI 流水线从零配置到深度定制【免费下载链接】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本文以开源仓库 open-code-review 的官方 CI 文档为主线系统讲解如何把 AI 代码评审工具 OpenCodeReview下文简称 OCR接入 GitHub Actions 与 GitLab CI从事件触发、runner 内安装与 LLM 配置、分支区间评审到解析 JSON 外壳、回贴内联评论的完整链路。读完本文你将能独立复制上游现成流水线、正确配置两类凭据、用 action/变量调优评审强度与并发并掌握--background、--rule、SARIF 上传、自定义 bot 身份等进阶定制能力。CI/CD 集成如何工作上游仓库在 examples/github_actions/ocr-review.yml 与 examples/gitlab_ci/.gitlab-ci.yml 各提供一条现成流水线。两者都是 CLI 参考中核心命令ocr review的薄包装遵循完全相同的六步模式在 PR / MR 事件上触发。新建 pull request、更新的 merge request或手动/open-code-review评论触发作业。在 runner 中安装ocr通常是npm install -g alibaba-group/open-code-review。runner 是临时的因此每次运行都重新安装。从 CI secret 经ocr config set配置 LLM端点、token、model。CI 环境没有持久化的~/.opencodereview可回退所以配置全部发生在作业内。以区间模式运行评审输出机器可读使 stdout 是干净的 JSON 外壳ocr review \ --from origin/base-branch \ --to origin/head-branch \ --format json \ --audience agent--format json给出可解析载荷--audience agent屏蔽进度行进度转到 stderr不污染 stdout 的 JSON。解析 JSON并遍历comments[]。通过 provider 的 review API 把评论回贴到 PR / MR。无有效行信息的条目文件级发现合并到摘要备注而非内联张贴若内联批量 API 拒绝请求张贴步骤也回退为普通摘要评论。始终涉及两类凭据OCR 用来生成发现的LLM 凭据端点 token model以及张贴步骤用来回贴评论的PR/MR 写 token。GitHub 配方通过GITHUB_TOKEN自动提供后者GitLab 建议显式配置GITLAB_API_TOKEN但对 fork MR 会回退使用内置CI_JOB_TOKEN它可通过/discussions发起讨论——为可靠性推荐使用专用 token。从源码看--format json与--audience agent的配合在 cmd/opencodereview/review_cmd.go 的用法示例中两者正是作为机器消费的标准组合出现。--audience agent把人类可读的进度行路由到 stderr确保管道下游解析 stdout 时不会遇到夹带的日志文本——这也是后续所有张贴脚本能稳定工作的前提。GitHub Actions它做什么上游工作流位于 examples/github_actions/ocr-review.yml在pull_request_targetopened、synchronize、reopened和issue_comment事件上触发后者正文以/open-code-review或open-code-review开头——让评审者通过在 PR 上评论按需重跑 OCR。用pull_request_target而非pull_request使即便从 fork 提交的 PR 也能用上 secretOCR 只读 diff不执行 PR 中的代码因此是安全的。通过npm install -g alibaba-group/open-code-review安装 OCR用ocr config set写配置再以分支区间模式运行核心命令--from merge-base --to head --format json。解析 JSON 外壳并通过 GitHub Pull Request Review API 把每条发现作为内联评审评论张贴。无行信息的评论合并到摘要正文。若批量提交失败回退为逐条张贴并在摘要评论中呈现统计。工作流里值得注意的一个实现细节是条件并发组concurrency.group中匹配的评审事件PR 事件 /open-code-review评论共享ocr-pr_number组并启用cancel-in-progress: true新评审会取消同一 PR 上过期的旧评审而不匹配的普通对话评论落入唯一的noop-run_id组立即跳过且不会打断正在运行的评审。GitHub Actions 会在 job 级if之前评估并发组若不这样设计任何普通评论都可能误杀运行中的评审。安装把工作流放进你的仓库也可直接拷贝仓库内文件mkdir -p .github/workflows curl -o .github/workflows/ocr-review.yml \ https://raw.githubusercontent.com/alibaba/open-code-review/main/examples/github_actions/ocr-review.yml必需 secret在Settings → Secrets and variables → Actions下设置Secret必需说明OCR_LLM_URL是LLM API 端点如https://api.openai.com/v1/chat/completions。OCR_LLM_AUTH_TOKEN是LLM API 的认证 token。此 CI secret 传给ocr config set llm.auth_token。OCR 的直接环境变量是OCR_LLM_TOKEN不是OCR_LLM_AUTH_TOKEN。OCR_LLM_MODEL否模型名。无默认——必须显式设置。OCR_LLM_USE_ANTHROPIC否Anthropic Claude 模型设为true。GITHUB_TOKEN自动提供工作流声明pull-requests: write以便张贴评审评论。注意OCR_LLM_MODEL与OCR_LLM_USE_ANTHROPIC在示例中作为variablesvars.使用而非 secretssecrets.因为后者与前者一样由工作流映射为 action input。工作流启动时还会运行ocr config set llm.extra_body {thinking: {type: disabled}}为不支持该字段的 LLM provider 关闭 thinking-mode 请求。若你的 provider 需保留 thinking-mode删除该行或在llm_extra_bodyinput 中覆盖。Action 参数上游工作流通过uses: alibaba/open-code-reviewmain把评审委托给可复用的 composite actionaction.yml。除上述凭据外以下 input 用于调节评审本身——在 action 步骤的with:下传入Input默认值说明effort传给ocr review --effort的评审强度预设low、medium或high不区分大小写。留空则沿用 CLI 默认值已配置的值否则为 medium。需要 OCR v1.10.0 或更新版本在更旧版本上 action 会提前以明确报错失败。max_tokens_budget传给ocr review --max-tokens-budget的 token 总量上限输入 输出。留空或0表示不限。超过上限后停止派发被跳过的文件记为failed(budget)已产生的部分结果仍会发布评审以 0 退出。llm_reasoning_effort面向支持reasoning_effort请求字段的模型如 GLM-5.x、OpenAI reasoning 模型的推理深度minimal、low、medium、high、max不区分大小写。经llm_extra_body合并进请求体因此所有已发布的 CLI 版本均可使用llm_extra_body中显式的reasoning_effort键优先于此 input。留空默认则不发送。仅适用于 OpenAI 兼容协议——Anthropic API 会拒绝未知请求体字段action 在该协议下会快速失败Anthropic 的 thinking 控制请改用llm_extra_body中的显式键。stream_progressfalse设为true时把[ocr]实时进度行流入工作流日志stderr 上的 human audience而不是在评审结束前保持静默。仅影响展示stderr 仍会写入文件供产物上传与评论张贴使用。- uses: alibaba/open-code-reviewmain with: llm_url: ${{ secrets.OCR_LLM_URL }} llm_auth_token: ${{ secrets.OCR_LLM_AUTH_TOKEN }} llm_model: ${{ vars.OCR_LLM_MODEL }} llm_use_anthropic: ${{ vars.OCR_LLM_USE_ANTHROPIC }} effort: high max_tokens_budget: 10000000 llm_reasoning_effort: low stream_progress: true完整 input 列表见 action.yml——包括张贴模式与跨 push 检查点等高级能力摘录如下Input默认值说明sticky_summarytrue摘要维度为true时原地更新已有摘要评论sticky而非每次运行张贴新评论。incrementalfalse增量维度为true时只追加(path, line range)与既有 bot 评审评论不重叠的内联评论。历史永不删除非破坏性。incremental_overlap_threshold0.6增量模式判断两条多行评论是否重叠的 IoU 阈值。两行单行评论同行即匹配单行 vs 多行永不匹配。checkpoint_rangefalse跨 push 检查点为true时一次完整完成选定范围的运行会在 sticky 摘要中记录其覆盖的 head下次运行只评审checkpoint..new head而非merge-base..new head。要求sticky_summary: true。full_reviewfalse即使启用checkpoint_range也强制一次完整评审reasonmanual_full_review。运行仍会记录新检查点。review_task_timeout15单文件/并发任务超时分钟1–120传给ocr review --timeout不是整次评审的墙钟上限。llm_timeout300每个模型请求的 LLM HTTP 超时秒。llm_extra_body{thinking: {type: disabled}}追加到 LLM 请求体的 JSON无对应环境变量经ocr config set llm.extra_body写入。ocr_versionlatestalibaba-group/open-code-review的 npm 版本规格要求 v1.9.6 或更新action 会在旧版本上提前失败。review_concurrency—传给ocr review --concurrency的值。background—传给ocr review --background的上下文。rule—传给ocr review --rule的自定义规则 JSON 路径。upload_artifactstrue把原始 JSON 结果与 stderr 上传为工作流产物必须传字符串true/false未加引号的 YAML 布尔不会匹配。route_severity_below把 severity 等于或低于该级别的发现从内联评论路由到 PR 摘要fail-open绝不丢弃发现。route_categories逗号分隔的类别列表从内联路由到摘要bug、security、performance、maintainability、test、style、documentation、other。review_comment_batch_size50单次createReview调用打包的内联评论数上限。checkpoint_range的 fail-closed 设计从 action.yml 的 Resolve review range 步骤可以看出只有当摘要评论存在且由本 token 发布、标记可读、base 未移动、配置指纹含llm_url、llm_model、effort、max_tokens_budget、rule内容、OCR 实际版本等十余个轴未变化、且git merge-base --is-ancestor能证明检查点是新 head 的祖先时才会收窄评审范围任何一环存疑都回退为完整范围评审并在range_summary/range_reason输出中说明原因如config_changed、base_changed、not_ancestor、unknown_object。规则文件按内容做 SHA-256 指纹——包括仓库自身的.opencodereview/rule.json——因此编辑规则一定会使旧检查点失效。定制以下都是对你刚复制的工作流文件.github/workflows/ocr-review.yml的编辑。背景上下文--background是效果最显著的单一参数——见适用于所有模式的提示。传入 PR 标题当标题遵循feat(auth): add OAuth2 support这样的语义约定时效果更好- name: Run OCR review env: PR_TITLE: ${{ github.event.pull_request.title }} BASE_REF: ${{ github.base_ref }} HEAD_REF: ${{ github.head_ref }} run: | ocr review \ --background $PR_TITLE \ --from origin/$BASE_REF \ --to origin/$HEAD_REF \ --format json --audience agent把 PR 可控的值通过env:传入不要把${{ }}直接插值进run:。GitHub 在 shell 解析该行之前就已把${{ }}做了文本替换因此包含 shell 元字符的 PR 标题或分支名会在你的 runner 上被执行注入攻击风险。自定义规则用--rule传入项目专属规则文件- name: Run OCR review env: BASE_REF: ${{ github.base_ref }} HEAD_REF: ${{ github.head_ref }} run: | ocr review --rule ./my-rules.json \ --from origin/$BASE_REF \ --to origin/$HEAD_REFschema 见评审规则。安全提示不要在 secret 生效范围内把rule指向来自 PR 分支的文件应使用 base 分支上的可信规则文件。并发默认 8 个并行子 agent——每个文件组一个。大 PR 上调低以免触发 LLM provider 速率限制- name: Run OCR review env: BASE_REF: ${{ github.base_ref }} HEAD_REF: ${{ github.head_ref }} run: | ocr review --concurrency 5 \ --from origin/$BASE_REF \ --to origin/$HEAD_REF触发模式默认工作流在 PRopened时以及以/open-code-review或open-code-review开头的 PR 评论时触发。两种常见调整在更多 PR 生命周期事件上运行如推送新 commit 时复审on: pull_request: types: [opened, synchronize, reopened, ready_for_review]使用不同评论关键字if: | github.event_name pull_request || (github.event_name issue_comment github.event.issue.pull_request startsWith(github.event.comment.body, /review))github.event.issue.pull_request检查确保评论在 PR 上而非普通 issue 上。上游示例工作流examples/github_actions/ocr-review.yml还额外加了github.event.comment.user.type ! Bot防止 PAT/App token 造成的自触发循环与author_association白名单MEMBER/OWNER/COLLABORATOR防止任意评论者消耗 LLM 配额两道防线若你修改了if中的关键字务必同步修改concurrency.group中的同一谓词。固定 OCR 版本默认工作流安装最新发布版本。固定- name: Install OpenCodeReview run: npm install -g alibaba-group/open-code-review1.0.0若使用 composite action则同时固定 action 引用与ocr_versioninput 两个坐标仅固定 action 引用不会冻结评审行为因为 CLI 仍按latest安装。以 GitHub App 身份发布默认评审评论来自github-actions[bot]。要以OpenCodeReview Bot这类自定义品牌的 bot 发布把GITHUB_TOKEN换成 GitHub App installation token。在Settings → Developer settings → GitHub Apps → New GitHub App创建 app。禁用 webhook此用例不需要。在Repository permissions授予Pull requestsRead and writeContentsRead-only用于取 diffMetadataRead-only必需从 app 设置页生成私钥并下载.pem文件。记下同页的App ID。把 app安装到你想 OCR 评审的仓库。Installation ID 出现在安装后 URL 中如https://github.com/settings/installations/12345→ ID 为12345。在Settings → Secrets and variables → Actions下添加三个 secretSecret值GITHUB_APP_IDApp ID。GITHUB_APP_PRIVATE_KEY.pem文件全部内容含-----BEGIN RSA PRIVATE KEY-----与-----END RSA PRIVATE KEY-----行。GITHUB_APP_INSTALLATION_IDInstallation ID。在评论张贴步骤中生成并使用 token- name: Get GitHub App Token id: app-token uses: actions/create-github-app-tokenv1 with: app-id: ${{ secrets.GITHUB_APP_ID }} private-key: ${{ secrets.GITHUB_APP_PRIVATE_KEY }} - name: Post review comments to PR uses: actions/github-scriptv7 with: github-token: ${{ steps.app-token.outputs.token }} script: | # ...existing post script...评审现在会以你 app 的名字而非github-actions[bot]发布。将发现上传到 GitHub Code ScanningSARIF--format sarif会把 SARIF 2.1.0 报告写入 stdout。把它重定向到文件并用 CodeQL 的upload-sarifaction 上传让发现出现在Security → Code scanning下- name: Run OCR review env: BASE_REF: ${{ github.base_ref }} HEAD_REF: ${{ github.head_ref }} run: | ocr review \ --from origin/$BASE_REF \ --to origin/$HEAD_REF \ --format sarif --audience agent results.sarif - uses: github/codeql-action/upload-sarifv3 with: sarif_file: results.sarifSARIF 是机器可读格式因此 OCR 会在 stdout 上抑制进度行results.sarif只包含报告本身。--preview不支持--format sarif——请运行完整的 review或ocr scan来生成报告。关于 SARIF 字段的具体渲染可对照 cmd/opencodereview/sarif.go 及其测试 sarif_test.go 查看实现。故障排查症状原因 / 修复Cannot find merge-basecheckout 步骤用了浅克隆但区间模式评审需要完整历史。上游工作流在actions/checkout上设fetch-depth: 0——编辑文件时保留该设置。Failed to parse OCR outputOCR_LLM_URL或OCR_LLM_AUTH_TOKEN缺失或错误。在Settings → Secrets and variables → Actions下复查值。评审评论落到错误行通常意味着评审开始到评论张贴之间 diff 发生了偏移。张贴脚本此时回退为普通 issue 评论——无需处理。注意。OCR_DEBUG环境变量目前在 OCR 中未实现——设置OCR_DEBUG: 1无效。此处记录以备将来接入。当前若需详细输出可检查工作流写到/tmp/ocr-result.json和/tmp/ocr-stderr.log的原始评审 JSON 和 stderr见下方故障排查或本地运行ocr review。使用 composite action 时默认会把这两个文件上传为ocr-review-result-run_id-run_attempt产物。GitLab CI上游流水线位于 examples/gitlab_ci/.gitlab-ci.yml。它做什么在merge_requests事件上触发所有 MR 事件——创建、更新、重开。在node:20镜像中运行安装 OCR通过ocr config set配置再以 MR diff 模式运行核心命令。用内联 Python 脚本解析 JSON 外壳把每条发现作为 GitLab Discussion在 diff 上内联张贴用 MR 的versions端点计算正确的base_sha/start_sha/head_sha以精确定位。对无法内联张贴的评论回退为普通 MR note并以摘要 note 收尾。上游流水线还做了几件值得注意的事examples/gitlab_ci/.gitlab-ci.yml声明GIT_DEPTH: 0强制完整克隆区间评审需要 merge-base用resource_group: mr-review-$CI_MERGE_REQUEST_IID与interruptible: true防止同一 MR 的旧流水线继续运行--to使用CI_COMMIT_SHA而非源分支名以兼容 fork MR 的 commit 解析产物路径放在项目内的.ocr/目录GitLab Runner 拒绝上传 build 目录之外的路径并通过 dotenv 报告向后续 stage 暴露统计量。安装把流水线放进仓库根注意.gitlab-ci.yml与post_review.py要一起拷贝脚本路径相对于流水线文件位置curl -o .gitlab-ci.yml \ https://raw.githubusercontent.com/alibaba/open-code-review/main/examples/gitlab_ci/.gitlab-ci.yml若已有.gitlab-ci.yml并想保留把配方放到其他路径并用include:引入include: - local: ci/ocr-review.gitlab-ci.yml必需 CI/CD 变量在Settings → CI/CD → Variables下设置变量必需掩码说明OCR_LLM_URL是否LLM API 端点 URL。OCR_LLM_AUTH_TOKEN是是API 认证 token。此 CI 变量传给ocr config set llm.auth_token。OCR 的直接环境变量是OCR_LLM_TOKEN不是OCR_LLM_AUTH_TOKEN。OCR_LLM_MODEL否否模型名。无默认——必须显式设置。GITLAB_API_TOKEN否是带apiscope 的 project / personal / group access token。可选——缺失时回退使用内置CI_JOB_TOKEN如对 fork MR。为可靠性推荐专用GITLAB_API_TOKEN。GitLab 拒绝短于 8 字符的变量因此流水线中llm.use_anthropic硬编码为false。要用 Anthropic Claude 模型直接编辑脚本。流水线启动时还会运行ocr config set llm.extra_body {thinking: {type: disabled}}为不支持该字段的 LLM provider 关闭 thinking-mode 请求。若你的 provider 需保留 thinking-mode删除该行。快速 bot 命名提示。对 Project Access Token 和 Group Access Tokentoken 的名字会出现在 MR 讨论旁。把 token 命名为OpenCodeReview Bot即可让评审讨论带上品牌名无需额外设置——当你不需要下文以服务账号身份发布中记录的更持久服务账号设置时很方便。流水线还支持一批可选变量用于微调评审行为来自 examples/gitlab_ci/.gitlab-ci.yml 头部注释OCR_REVIEW_CONCURRENCY--concurrency默认 8、OCR_BACKGROUND--background如 MR 标题、OCR_RULE--rule、OCR_VERSIONnpm 版本规格默认latest固定如1.8.8或~1.8可获得可复现评审、OCR_LANGUAGE评审输出语言、OCR_LLM_AUTH_HEADER自定义认证头名、OCR_LLM_EXTRA_HEADERSKV,KV形式的额外头、OCR_LLM_TIMEOUTOCR 原生从环境变量读取无需ocr config set。定制以下都是对你刚复制的.gitlab-ci.yml的编辑。背景上下文把 MR 标题传给--background——当标题遵循feat(auth): add OAuth2 support这样的语义约定时效果更好script: - | ocr review \ --background $CI_MERGE_REQUEST_TITLE \ --from origin/$CI_MERGE_REQUEST_TARGET_BRANCH_NAME \ --to ${CI_COMMIT_SHA} \ --format json --audience agent自定义规则与并发与 GitHub Actions 配方相同的参数——--rule传项目专属规则文件--concurrency限制并行子 agent默认 8每个文件组一个script: - | ocr review --rule ./my-rules.json --concurrency 5 \ --from origin/$CI_MERGE_REQUEST_TARGET_BRANCH_NAME \ --to ${CI_COMMIT_SHA}规则 schema 见评审规则。固定 OCR 版本script: - npm install -g alibaba-group/open-code-review1.0.0避免每次推送都复审only: [merge_requests]在每次MR 更新时触发对长生命周期 MR 会消耗大量 LLM token。GitLab 无原生仅在创建时事件因此推荐模式是运行评审前检测已有 OCR note若有则跳过。把ocr review调用替换为 Python wrapperimport json, os, sys, urllib.request GITLAB_URL os.environ.get(CI_SERVER_URL, https://gitlab.com) PROJECT_ID os.environ[CI_PROJECT_ID] MR_IID os.environ[CI_MERGE_REQUEST_IID] API_TOKEN os.environ[GITLAB_API_TOKEN] url ( f{GITLAB_URL}/api/v4/projects/{PROJECT_ID} f/merge_requests/{MR_IID}/notes?per_page100 ) req urllib.request.Request(url, headers{PRIVATE-TOKEN: API_TOKEN}) with urllib.request.urlopen(req) as resp: notes json.loads(resp.read().decode()) if any(OpenCodeReview in n.get(body, ) for n in notes): print(OCR already reviewed this MR. Skipping to save tokens.) sys.exit(0) # ...otherwise call ocr review ... as usual and write the JSON to # the file the posting step expects.要在此之后强制复审从 MR 删除之前的 OCR note——下次流水线运行会看不到 OCR note便会继续。自托管 GitLab无需改代码。张贴脚本读CI_SERVER_URLGitLab 在每个 runner 上自动设置因此开箱即可与你自己的实例通信。只需确保GITLAB_API_TOKEN由你的自托管实例签发而非gitlab.com。以服务账号身份发布默认评审讨论出现在GITLAB_API_TOKEN所属用户名下。改用项目级服务账号即可获得OpenCodeReview Bot这类自定义品牌的 bot 身份。在Project → Settings → Service Accounts → New service account创建服务账号。你选的名字如OpenCodeReview Bot会出现在 MR 讨论旁。在Settings → Members → Invite member邀请它到项目。搜索服务账号名并分配Developer或Maintainer——两者都有张贴讨论所需权限。在Settings → Service Accounts →该账号→ Add new token签发 access token。所需 scopeapi。立即复制 token——GitLab 只显示一次。在Settings → CI/CD → Variables替换 token 值——用服务账号的 token 替换现有GITLAB_API_TOKEN值变量名保持不变。讨论现在以服务账号名而非最初创建 token 的用户名发布。故障排查症状原因 / 修复Cannot find merge-baserunner 用了浅克隆。上游流水线设GIT_DEPTH: 0强制完整克隆——编辑文件时保留该设置。张贴时API error 403GITLAB_API_TOKEN缺apiscope、不是项目成员或——自托管时——由不同实例签发。以apiscope 重签并在Settings → CI/CD → Variables下重新添加。Failed to parse OCR outputOCR_LLM_URL或OCR_LLM_AUTH_TOKEN错误。在Settings → CI/CD → Variables下复查值。内联评论落到错误行GitLab 内联讨论要求精确 SHA 匹配张贴脚本取versions元数据以得到正确的base_sha/start_sha/head_sha。若某条发现仍无法锚定回退为普通 MR note。流水线把原始评审 JSON 写到/tmp/ocr-result.jsonstderr 写到/tmp/ocr-stderr.log。可在 debug 步骤中 cat 它们检查 OCR 返回了什么script: - cat /tmp/ocr-result.json - cat /tmp/ocr-stderr.log从源码看张贴脚本的健壮性设计GitLab 配方的核心 examples/gitlab_ci/post_review.py 与 GitHub Action 的张贴模块 scripts/github-actions/post-review-comments.js 保持行为对齐——每条内联评论带[category · severity]徽章张贴前按path → start_line → end_line → 原始索引确定性排序每次内联讨论内嵌不可见的 HTML id 标签!-- ocr-... --5xx/超时重试前先查询该 id 是否已落库实现幂等去重对 400 位置解析失败脚本会拉取 MR diff 清单把发现分类为 valid/invalid/unknown证明在 diff 之外的发现降级进摘要而非盲目重试增量模式用 IoU 阈值默认 0.6判断多行评论是否与历史 bot 讨论重叠。脚本只依赖标准库json、urllib任何标准 python3 镜像开箱即用且配套 post_review_test.py 单元测试覆盖了上述全部行为。另见CLI 参考——两条流水线消费的 JSON 结构含comments[]与 manifest 字段从头写 CI 脚本时有用配置文档见configuration。评审规则——自定义规则文件 schema--rule的完整字段说明。其他平台集成可参考 examples 下的 bitbucket_pipelines、codeup_ci、gerrit_ci、gitflic_ci 等同类配方。【免费下载链接】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），仅供参考