This is an automated email from the ASF dual-hosted git repository.
morningman pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/doris-website.git
The following commit(s) were added to refs/heads/master by this push:
new ea6fa9ff4c0 [doc](community) Add Review and CI guide (#4115)
ea6fa9ff4c0 is described below
commit ea6fa9ff4c0e358e1f3a16b6237c4b5928533b59
Author: Mingyu Chen (Rayner) <[email protected]>
AuthorDate: Fri Sep 4 13:15:16 2026 +0800
[doc](community) Add Review and CI guide (#4115)
## Summary
- add an English and Chinese Review and CI guide after the Pull Request
guide
- document workflow approval, Slack review requests, local and online AI
review, and required CI checks
- list all effective TeamCity comment commands and explain Code Owner
approval and the merge checklist
## Validation
- `git diff --check`
- `yarn docs:links:changed`
- `yarn docs:i18n-sync:changed`
- `PWA_SERVICE_WORKER_URL=https://doris.apache.org/sw.js yarn docusaurus
build --locale en --locale zh-CN` (completed with repository-existing
warnings)
Co-authored-by: morningman <[email protected]>
---
community/how-to-contribute/review-and-ci.md | 190 +++++++++++++++++++++
.../current/how-to-contribute/review-and-ci.md | 190 +++++++++++++++++++++
sidebarsCommunity.json | 1 +
3 files changed, 381 insertions(+)
diff --git a/community/how-to-contribute/review-and-ci.md
b/community/how-to-contribute/review-and-ci.md
new file mode 100644
index 00000000000..6d6046c6db3
--- /dev/null
+++ b/community/how-to-contribute/review-and-ci.md
@@ -0,0 +1,190 @@
+---
+title: Review and CI
+language: en
+description: How to review an Apache Doris Pull Request, run CI, address
findings, and get the change merged.
+keywords:
+ - Apache Doris
+ - Pull Request Review
+ - CI
+ - TeamCity
+ - AI Review
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+<!-- Knowledge type: procedure -->
+<!-- Applicable scenarios: after opening a PR / review / CI / merge -->
+
+After opening a Pull Request (PR), a contributor must complete code review, CI
checks, and any required fixes before the PR can be merged. This guide covers
the complete process from opening a PR through merge. To learn how to open a
PR, see the [Pull Request guide](./pull-request.md).
+
+Process overview:
+
+1. If you are not a Committer, ask a Committer to inspect the change and
approve the CI workflow.
+2. Review your own change, and optionally run a local AI review with the
`doris-repo-review` skill.
+3. After the CI workflow is approved, trigger the TeamCity checks from a PR
comment.
+4. Address CI and review findings, and make sure every required check passes
for the current commit.
+5. After a Reviewer and the relevant Code Owners approve the code, ask a
Committer to merge the PR.
+
+## 1. Ask a Committer to approve the CI workflow
+
+When a non-Committer opens a PR, the CI workflow may wait for approval from a
community member with the required permissions. Ask a Committer to inspect the
change and approve the workflow. Workflow approval only allows CI to execute
code from the PR. It does not mean that the Committer has approved the code or
agreed to merge it.
+
+Join the [Apache Doris Slack
community](https://doris.apache.org/slack?utm_source=website&utm_medium=docs&utm_content=review_ci)
and post the following information in the `#dev` channel so the community can
identify a suitable Reviewer:
+
+```text
+PR: <PR URL>
+Module: <affected module>
+Change: <one-sentence purpose>
+Local validation: <tests already run>
+Help needed: Approve CI workflow / Review
+```
+
+If you do not know whom to contact, check recently merged PRs for the module
or the commit history of the affected files. You can then invite a Committer
familiar with that module in `#dev`.
+
+## 2. Review the change locally
+
+While waiting for workflow approval or remote CI, complete a self-review of
the PR:
+
+- Confirm that the changed files match the PR description and contain no
unrelated edits.
+- Check normal paths, error paths, boundary conditions, and compatibility
effects.
+- Confirm that new behavior has tests and that existing tests were not removed
or weakened without a reason.
+- Update configuration references, user documentation, error messages, and
upgrade notes when needed.
+- Confirm that logs do not contain passwords, tokens, keys, or other secrets.
+
+### Run a local AI review with `doris-repo-review`
+
+Apache Doris provides the [`doris-repo-review`
skill](https://github.com/apache/doris-skills/tree/main/skills/doris-repo-review).
It reviews a PR from a local Doris source checkout with the same method as the
online Code Review pipeline. The skill does not compile the code or run tests,
so it does not replace CI.
+
+Install the Apache Doris skills:
+
+```bash
+npx skills add apache/doris-skills
+```
+
+The local environment requires `git`, an authenticated `gh` CLI, `jq`, and
`python3`. The Doris checkout must have full Git history. From a local
`apache/doris` source checkout, run the following command in an Agent that
supports skills:
+
+```text
+/doris-repo-review https://github.com/apache/doris/pull/<PR number>
+```
+
+You can add a review focus after the command:
+
+```text
+/doris-repo-review https://github.com/apache/doris/pull/<PR number> focus on
compatibility and error handling
+```
+
+The skill aligns the current working directory with the exact PR commit and
writes English and Chinese review documents under `review-docs/`. Commit or
stash tracked local changes yourself before running it. The skill does not
stash or delete changes for you, and it may leave the working directory at a
detached HEAD.
+
+The skill automatically posts a machine-readable PASS comment from the locally
authenticated `gh` account when all of the following conditions hold:
+
+- The review verdict is `APPROVE`, with no `Blocker` or `Major` finding.
+- The review converged and the review documents passed validation.
+- The selected model and reasoning effort meet the skill requirements.
+- The PR head did not change during review.
+
+The skill does not post a PASS comment when the verdict is `REQUEST_CHANGES`,
the review did not converge, the runtime is not qualified, or the PR head
changed. This comment is a receipt for the local AI review of one commit. It is
not a human Apache approval and does not replace a Reviewer's code approval.
+
+## 3. Trigger TeamCity CI
+
+After the CI workflow is approved, post the following comment on the PR to
trigger the TeamCity pipeline:
+
+```text
+run buildall
+```
+
+`run buildall` triggers the complete applicable set of checks based on the
PR's changed files. Prefer this command for a normal validation run. To run or
retry one group of checks, use another command currently supported by the
[TeamCity trigger
workflow](https://github.com/apache/doris/blob/master/.github/workflows/comment-to-trigger-teamcity.yml).
+
+| Command | Purpose |
+|---------|---------|
+| `run buildall` | Trigger the complete applicable compilation and test set |
+| `run compile` | Trigger compilation checks |
+| `run beut` | Trigger BE unit tests |
+| `run feut` | Trigger FE unit tests |
+| `run cloudut` | Trigger Cloud unit tests |
+| `run p0` | Trigger P0 regression tests |
+| `run p1` | Trigger P1 regression tests |
+| `run external` | Trigger External regression tests |
+| `run cloud_p0` | Trigger Cloud P0 regression tests |
+| `run cloud_p1` | Trigger Cloud P1 regression tests |
+| `run vault_p0` | Trigger Vault P0 regression tests |
+| `run nonConcurrent` | Trigger regression tests that cannot run concurrently |
+| `run check_coverage` | Trigger the code coverage check |
+| `run performance` | Trigger performance tests |
+
+If the PR changes credential-sensitive pipeline scripts under
`regression-test/pipeline/`, individual test commands are blocked. After
reviewing the scripts for safety, a Committer must use `run buildall` to
acknowledge the change and trigger the pipeline.
+
+## 4. Determine whether CI passed
+
+The PR checks include required and non-required checks:
+
+- **Required checks**: Every required check for the current PR head must pass
before the PR can be merged.
+- **Non-required checks**: These results provide additional evidence but do
not directly block merge. If one fails, still determine whether the change
caused the failure instead of ignoring it.
+
+When CI fails, open the check logs and determine whether the cause is a code
defect, a test defect, an infrastructure problem, or a flaky test. Fix code and
test defects and push a new commit. For a suspected infrastructure problem or
flaky test, add the failed log URL and your reasoning to the PR, then ask a
Committer or module maintainer to help retry or investigate it.
+
+Every push changes the PR head. Use only the checks for the latest commit. A
green check or AI Review PASS for an older commit does not cover the current
commit.
+
+## 5. Ask a Committer to trigger online AI review
+
+A Committer or another member with the required repository permissions can
trigger online AI review by posting this PR comment:
+
+```text
+/review
+```
+
+The command can also include a focus:
+
+```text
+/review focus on compatibility and error handling
+```
+
+Online AI review uses the same review method as the `doris-repo-review` skill,
but the job enters an online queue and must wait for available resources. Check
the `code-review` status and its GitHub Actions logs in the PR Checks area. Do
not trigger duplicate runs simply because a job remains Queued or Running for a
while.
+
+A successful `code-review` check means that the online review completed and
submitted a review. It does not mean that the review found no problems. Read
the review summary and inline comments and address its findings.
+
+## 6. Address review findings and complete the merge
+
+### Obtain Code Owner approval
+
+Apache Doris uses
[`.github/CODEOWNERS`](https://github.com/apache/doris/blob/master/.github/CODEOWNERS)
to assign Code Owners to selected code paths. When a PR changes one of these
paths, GitHub requests a review from the corresponding person or team. A module
that requires Code Owner review must receive approval from the relevant Code
Owner before the PR can be merged.
+
+Code Owner approval, CI workflow approval, and approval from a general
Reviewer are separate requirements. One cannot replace another. Check the PR
Reviewers area and merge requirements for a pending Code Owner review. If you
do not know whom to contact, use the current `CODEOWNERS` file as the source of
truth and post the PR URL in the Slack `#dev` channel. This guide does not copy
the Code Owner list because the repository configuration can change.
+
+### Address review findings
+
+After receiving human or AI review feedback:
+
+1. Decide whether each finding applies to the current change.
+2. Address valid findings in the code, tests, or documentation, and reply with
what changed.
+3. For an inapplicable finding, explain the technical reason and supporting
evidence.
+4. Resolve a conversation only after the issue has been addressed.
+5. After pushing a new commit, rerun affected CI and review checks. An AI
Review PASS bound to an older commit does not cover the new commit.
+6. If the PR has conflicts, rebase it onto the latest target branch and
resolve them.
+
+Ask a Committer to complete the merge after the PR meets all of these
conditions:
+
+- The PR description is complete and its scope is clear.
+- All review findings have been addressed.
+- Every required check passes for the latest PR head.
+- The PR has no unresolved conflict with the target branch.
+- A Reviewer has approved the code.
+- The Code Owners for the affected paths have approved the code as required.
+
+The Committer makes the final merge decision based on the review, CI results,
and project merge policy.
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs-community/current/how-to-contribute/review-and-ci.md
b/i18n/zh-CN/docusaurus-plugin-content-docs-community/current/how-to-contribute/review-and-ci.md
new file mode 100644
index 00000000000..eddb908fba6
--- /dev/null
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs-community/current/how-to-contribute/review-and-ci.md
@@ -0,0 +1,190 @@
+---
+title: Review and CI
+language: zh-CN
+description: Apache Doris Pull Request 提交后的 Review、CI 触发、问题修复与合入流程。
+keywords:
+ - Apache Doris
+ - Pull Request Review
+ - CI
+ - TeamCity
+ - AI Review
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+<!-- 知识类型: 操作步骤 -->
+<!-- 适用场景: PR 提交后 / Review / CI / 合入 -->
+
+创建 Pull Request（PR）后，贡献者还需要完成代码 Review、CI 检查和问题修复，PR 才能进入合入阶段。本文介绍从提交 PR
到最终合入的完整流程。关于创建 PR 的方法，请参阅[代码提交指南](./pull-request.md)。
+
+流程概览：
+
+1. 如果您不是 Committer，请联系 Committer 审核并 Approve CI workflow。
+2. 自查改动，并按需使用 `doris-repo-review` skill 在本地执行 AI Review。
+3. CI workflow 获得 Approve 后，通过 PR 评论触发 TeamCity 检查。
+4. 修复 CI 和 Review 发现的问题，确保当前提交的所有 Required checks 通过。
+5. 获得 Reviewer 和相关 Code Owner 的代码 Approve 后，由 Committer 合入 PR。
+
+## 1. 请求 Committer Approve CI workflow
+
+非 Committer 提交 PR 后，CI workflow 可能会等待具有权限的社区成员批准。此时，请联系一名 Committer 检查改动并
Approve workflow。workflow Approve 只表示允许 CI 执行 PR 中的代码，并不代表 Committer
已经批准代码改动或同意合入。
+
+建议加入 [Apache Doris Slack
社群](https://doris.apache.org/slack?utm_source=website&utm_medium=docs&utm_content=review_ci)，在
`#dev` 频道发送以下信息，以便社区快速找到合适的 Reviewer：
+
+```text
+PR: <PR 链接>
+模块: <涉及的模块>
+变更: <一句话说明改动目的>
+本地验证: <已经执行的测试>
+需要帮助: Approve CI workflow / Review
+```
+
+如果您不确定应该联系谁，可以查看相关模块近期合入的 PR 或相关文件的提交历史，再在 `#dev` 频道中邀请熟悉该模块的 Committer 参与。
+
+## 2. 在本地完成 Review
+
+等待 workflow Approve 或远程 CI 时，先对 PR 做一次完整自查：
+
+- 确认改动范围与 PR 描述一致，没有混入无关修改。
+- 检查正常路径、异常路径、边界条件和兼容性影响。
+- 确认新增行为有对应测试，已有测试没有被无理由删除或弱化。
+- 确认配置、用户文档、错误信息和升级说明已经按需更新。
+- 确认日志中不包含密码、Token、密钥或其他敏感信息。
+
+### 使用 `doris-repo-review` 进行本地 AI Review
+
+Apache Doris 提供了 [`doris-repo-review`
skill](https://github.com/apache/doris-skills/tree/main/skills/doris-repo-review)，可以在本地
Doris 源码仓库中按在线 Code Review 流水线相同的方法审查 PR。该 skill 不编译代码或运行测试，因此不能替代 CI。
+
+首先安装 Apache Doris skills：
+
+```bash
+npx skills add apache/doris-skills
+```
+
+本地环境需要具备 `git`、已完成认证的 `gh` CLI、`jq` 和 `python3`，Doris 仓库需要包含完整 Git 历史。进入本地
`apache/doris` 源码仓库后，在支持 skill 的 Agent 中执行：
+
+```text
+/doris-repo-review https://github.com/apache/doris/pull/<PR 编号>
+```
+
+也可以在命令末尾补充重点审查内容：
+
+```text
+/doris-repo-review https://github.com/apache/doris/pull/<PR 编号> focus on
compatibility and error handling
+```
+
+skill 会将当前工作目录对齐到 PR 的准确提交，并在 `review-docs/` 中生成中英文 Review
文档。运行前请先提交或自行暂存已跟踪文件的本地修改。skill 不会替您暂存或删除修改，并可能将当前工作目录切换到 detached HEAD。
+
+当 Review 同时满足以下条件时，skill 会通过本机 `gh` 登录账号，在 PR 中自动发布一条与当前 commit 绑定的机器可读 PASS
评论：
+
+- Review 结论为 `APPROVE`，没有 `Blocker` 或 `Major` 问题。
+- Review 已收敛，并且 Review 文档通过校验。
+- 使用的模型和推理强度符合 skill 的要求。
+- PR head 在 Review 期间没有变化。
+
+如果 Review 结论为 `REQUEST_CHANGES`、Review 未收敛、运行环境不符合要求，或 PR head 已变化，skill 不会发布
PASS 评论。该 PASS 评论是本地 AI Review 的结果凭证，不是 Apache 社区的人工批准，也不能代替 Reviewer 的代码
Approve。
+
+## 3. 触发 TeamCity CI
+
+CI workflow 获得 Approve 后，可以在 PR 中评论以下命令，触发 TeamCity 流水线：
+
+```text
+run buildall
+```
+
+`run buildall` 会根据 PR 的变更范围触发完整的检查组合。通常优先使用该命令。需要单独执行或重试某一类检查时，可以使用 [TeamCity
触发
workflow](https://github.com/apache/doris/blob/master/.github/workflows/comment-to-trigger-teamcity.yml)
当前支持的其他命令。
+
+| 命令 | 作用 |
+|------|------|
+| `run buildall` | 根据变更范围触发完整的编译和测试组合 |
+| `run compile` | 触发编译检查 |
+| `run beut` | 触发 BE 单元测试 |
+| `run feut` | 触发 FE 单元测试 |
+| `run cloudut` | 触发 Cloud 单元测试 |
+| `run p0` | 触发 P0 回归测试 |
+| `run p1` | 触发 P1 回归测试 |
+| `run external` | 触发 External 回归测试 |
+| `run cloud_p0` | 触发 Cloud P0 回归测试 |
+| `run cloud_p1` | 触发 Cloud P1 回归测试 |
+| `run vault_p0` | 触发 Vault P0 回归测试 |
+| `run nonConcurrent` | 触发不能并发执行的回归测试 |
+| `run check_coverage` | 触发代码覆盖率检查 |
+| `run performance` | 触发性能测试 |
+
+如果 PR 修改了 `regression-test/pipeline/` 下涉及凭证访问的流水线脚本，单项测试命令会被阻止。Committer
检查脚本安全性后，需要使用 `run buildall` 明确确认并触发流水线。
+
+## 4. 判断 CI 是否通过
+
+PR 页面中的检查分为 Required 和非 Required 两类：
+
+- **Required checks**：当前 PR head 对应的所有 Required checks 必须通过，PR 才能合入。
+- **非 Required checks**：结果用于辅助判断，不直接阻止合入。即使失败，也应确认失败是否由本次改动引起，不能直接忽略。
+
+CI 失败后，打开对应检查的日志，先判断问题属于代码错误、测试错误、环境问题还是不稳定测试。代码或测试有问题时，修复后 push
新提交。怀疑基础设施或不稳定测试时，在 PR 中附上失败日志链接和判断依据，再请 Committer 或模块维护者协助重试或排查。
+
+每次 push 都会改变 PR head。请以最新提交对应的检查结果为准，不要把旧提交的绿色检查或 AI Review PASS 当作当前提交的结果。
+
+## 5. 由 Committer 触发在线 AI Review
+
+Committer 或具有相应仓库权限的成员可以在 PR 中评论以下命令，触发在线 AI Review：
+
+```text
+/review
+```
+
+也可以在命令后说明重点，例如：
+
+```text
+/review focus on compatibility and error handling
+```
+
+在线 AI Review 与 `doris-repo-review` skill 使用一致的审查方法，但任务需要进入在线队列并等待可用资源。请在 PR 的
Checks 区域查看 `code-review` 状态和对应的 GitHub Actions 日志。不要因为任务暂时处于 Queued 或 Running
状态而重复触发。
+
+`code-review` 检查成功表示在线 Review 已经执行完成并提交了 Review 结果，不代表 Review 一定没有发现问题。请继续阅读
AI Review 的总结和行级评论，并处理其中的问题。
+
+## 6. 处理 Review 意见并完成合入
+
+### 获得 Code Owner Approve
+
+Apache Doris 使用
[`.github/CODEOWNERS`](https://github.com/apache/doris/blob/master/.github/CODEOWNERS)
为部分代码路径指定 Code Owner。PR 修改这些路径时，GitHub 会根据 `CODEOWNERS` 请求相应的个人或团队参与 Review。需要
Code Owner Review 的模块必须获得对应 Code Owner 的 Approve，才能完成合入。
+
+Code Owner Approve 与 CI workflow Approve、普通 Reviewer Approve
是不同的检查项，三者不能相互替代。请在 PR 的 Reviewers 区域和合入条件中确认是否仍在等待 Code Owner
Review。如果不确定应该联系谁，请以 `CODEOWNERS` 的最新内容为准，并在 Slack `#dev` 频道中附上 PR
链接寻求帮助。本文不列出具体 Code Owner 名单，以免名单与仓库配置不一致。
+
+### 处理 Review 意见
+
+收到人工或 AI Review 意见后：
+
+1. 逐条确认意见是否适用于当前改动。
+2. 对合理意见修改代码、补充测试或文档，并在 PR 中回复处理结果。
+3. 对不适用的意见说明技术原因和验证依据。
+4. 只在问题确实处理完成后 Resolve 对话。
+5. push 新提交后，重新执行受影响的 CI 和 Review。与旧 commit 绑定的 AI Review PASS 不能覆盖新提交。
+6. 如有冲突，rebase 最新目标分支并解决冲突。
+
+PR 满足以下条件后，可以请 Committer 完成最终合入：
+
+- PR 描述完整，改动范围清晰。
+- Review 意见已经处理完毕。
+- 最新 PR head 的所有 Required checks 已通过。
+- PR 与目标分支没有未解决的冲突。
+- Reviewer 已给出代码 Approve。
+- PR 涉及的 Code Owner 已按要求给出 Approve。
+
+最终由 Committer 根据 Review 结论、CI 结果和项目合入策略完成合入。
diff --git a/sidebarsCommunity.json b/sidebarsCommunity.json
index e99903f2360..f93b2c03cb2 100644
--- a/sidebarsCommunity.json
+++ b/sidebarsCommunity.json
@@ -18,6 +18,7 @@
"items": [
"how-to-contribute/contribute-to-doris",
"how-to-contribute/pull-request",
+ "how-to-contribute/review-and-ci",
{
"type": "category",
"label": "Documentation Contribution",
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
