openUBMC 社区 Bot 使用指南
在 Issue 或 Pull Request 的评论区输入命令，Robot 即自动执行。本文以目标效果为线索说明每条命令的使用场景。
一、Issue
推进Issue进度
缺陷类 Issue 按以下流程流转，每个阶段由对应角色触发：
---
config:
look: handDrawn
theme: neutral
---
flowchart LR
A[待修复] -->|/todo2fixing| B[修复中]
B -->|/fixing2UAT| C[待验收]
C -->|/UAT2done| D[已修复]
A -->|/todo2suspended| E[已挂起]
A -->|/todo2rejected| F[已拒绝]
style D fill:#fbb
| 我想… | 评论 | 谁能操作 |
|---|---|---|
| 开始修复这个缺陷 | /todo2fixing |
Maintainer / Committer / Contributor |
| 修复完成，等待验收 | /fixing2UAT |
Maintainer / Committer / Contributor |
| 验收通过，关闭修复流程 | /UAT2done |
sig-QA Maintainer / Committer |
| 暂时搁置，不继续处理 | /todo2suspended |
Maintainer / Committer / Contributor |
| 非缺陷，不予处理 | /todo2rejected |
Maintainer / Committer / Contributor |
需求类 Issue 按以下流程流转，每个阶段由对应角色触发：
---
config:
look: handDrawn
theme: neutral
---
flowchart TD
A[待办的] -->|/todo2accepted| B[已接纳]
B -->|/accepted2developing| C[开发中]
C -->|/developing2testing| D[转测中]
D -->|/testing2UAT| E[待验收]
E -->|/UAT2done| F[已完成]
A -->|/todo2suspended| H[已挂起]
H -->|/suspended2accepted| B
A -->|/todo2rejected| I[已拒绝]
I -->|/rejected2accepted| B
style B fill:#fbb
style F fill:#fbb
| 我想… | 评论 | 谁能操作 |
|---|---|---|
| 接纳这个需求 | /todo2accepted/suspended2accepted/rejected2accepted |
sig-release-management Maintainer |
| 修复完成，等待验收 | /accepted2developing |
Maintainer / Committer / Contributor |
| 修复完成，等待验收 | /developing2testing |
Maintainer / Committer / Contributor |
| 验收通过，关闭修复流程 | /UAT2done |
sig-QA Maintainer / Committer |
| 暂时搁置，不继续处理 | /todo2suspended |
Maintainer / Committer / Contributor |
| 该需求不予处理 | /todo2rejected |
Maintainer / Committer / Contributor |
更换负责人
---
config:
look: handDrawn
theme: neutral
---
flowchart LR
A[当前负责人] -->|"/assign @账号ID"| B[新负责人]
B -->|/unassign| C[默认负责人]
| 我想… | 评论 | 谁能操作 |
|---|---|---|
| 把 Issue 交给某人处理 | /assign @账号ID |
Issue 作者、管理员、SIG Maintainer / Committer |
| 取消指派，恢复默认负责人 | /unassign |
Issue 作者、管理员、SIG Maintainer / Committer |
关闭或重新打开
| 我想… | 评论 | 谁能操作 |
|---|---|---|
| 关闭这个 Issue | /close |
Issue 作者、管理员、SIG Maintainer / Committer |
| 重新打开已关闭的 Issue | /reopen |
Issue 作者、管理员、SIG Maintainer / Committer |
二、PullRequest
PR合入流程概述
PR 从提交到合入需经过 CLA 检查、代码审核、门禁三道关口：
---
config:
look: handDrawn
theme: neutral
---
flowchart TD
A([提交 PR]) --> check
subgraph check[合入检查]
B[CLA 检查] -->|未通过| B1[签署 CLA或者修改 commit 中的邮箱\n后评论/check-cla] -->|重新检查| B
C[代码审核\n/lgtm + /approve] --> A1[PR代码更新] -->|重新审核| C
D[门禁 CI 通过] -->|未通过| D1[评论/check-cla] -->|重新检查| D
I[评审意见解决完]
M["PR需要关联Issue"] -->|未关联| M1[在PR描述中粘贴Issue链接]
end
check -->|检查通过| E([合入])
G["评论/check-pr"] --> check
解决CLA检查不通过
PR 提交后 Robot 自动检查 CLA，未签署时 PR 无法合入。
| 我想… | 评论 | 谁能操作 |
|---|---|---|
| 签署 CLA 或者修改 commit 中的邮箱后重新触发检查 | /check-cla |
任何人 |
| 撤销已有的 CLA 认证标签 | /cla cancel |
管理员、SIG Maintainer / Committer |
[!NOTE]
CLA 检查不通过时，先完成以下任意一项，再评论/check-cla：
- 用 commit 所用邮箱前往官网签署 CLA
- 将 commit 中的邮箱改为已签署 CLA 的邮箱
进行代码审核
| 我想… | 评论 | 谁能操作 |
|---|---|---|
| 表示代码改动已审核通过 | /lgtm |
管理员、SIG Maintainer / Committer |
| 撤回我的审核通过意见 | /lgtm cancel |
管理员、SIG Maintainer / Committer |
| 批准这个 PR 可以合入 | /approve |
管理员、SIG Maintainer / Committer |
| 撤回批准 | /approve cancel |
管理员、SIG Maintainer / Committer |
[!IMPORTANT]
lgtm和approved两个标签均为合入必要条件，缺少其中任意一个，PR 都不会合入。
推动PR合入
| 我想… | 评论 | 谁能操作 |
|---|---|---|
| 重新跑一次门禁 CI | /retest |
任何人 |
| 检查 PR 是否关联了 Issue | /check-issue |
任何人 |
| 查看当前 PR 卡在哪个环节 / 触发自动合入 | /check-pr |
任何人 |
评论 /check-pr 后，Robot 会反馈具体阻断原因：缺少标签、存在冲突标签，或其他合规问题。
指定合并方式
不指定时，默认为普通合并（merge commit）。
| 我想… | 评论 | 效果 |
|---|---|---|
| 多个 commit 合并成一个再入库 | /squash |
扁平化合并，保持目标分支历史整洁 |
| 取消扁平化合并 | /squash cancel |
恢复为默认合并 |
| 把我的 commit 接在目标分支末端 | /rebase |
变基合并，线性历史 |
| 取消变基合并 | /rebase cancel |
恢复为默认合并 |
谁能操作：管理员、SIG Maintainer / Committer
附录：权限速查
| 效果 | 任何人 | 作者 | Contributor | Committer / Maintainer |
|---|---|---|---|---|
| 重新检查 CLA / 重跑 CI / 查看合入状态 / 发布 | ✓ | |||
| 关闭、重新打开 | ✓ | ✓ | ||
| 更换负责人 | ✓ | ✓ | ✓ | |
| Issue 普通状态流转 | ✓ | ✓ | ||
| 需求 Issue 接纳 | ✓（sig-release-management maintainer） | |||
| 需求/缺陷 Issue 终态 | ✓（sig-QA） | |||
| 代码审核、批准、CLA 撤销、合并方式 | ✓ |