Skip to content

C
Community

OpenHarmony / Community
1 年多 前同步成功

通知 55
Star 210
Fork 5
C
Community
提交 3137628b 编写于 作者: K kenneth 提交者： jinguang
浏览文件
操作

!1480 更新CI Bot命令使用场景 

* 更新CI Bot命令使用场景
上级 8bc82468
显示空白变更内容
内联 并排
Showing with 29 addition and 28 deletion
zh/infrastructure/build_command.md
浏览文件 @ 3137628b
......@@ -11,33 +11,34 @@
## Pull Request评论支持命令清单
| 评论输入命令 | 是否必选 | 使用场景 | 命令触发角色 |
| ------------------ | ------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------ |
| start build | **必选** | 触发编译构建测试 | PR创建人<br>committer |
| --------------------------------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------ |
| start build | **必选** | 触发编译构建测试<br>构建门禁通过后，CI Bot会提醒审核检视人员处理PR | PR创建人<br>Committer |
| stop build | 可选 | 停止编译构建测试 | PR创建人 |
| submit | 可选 | 自动合入异常时，手工触发合入，检查通过后自动合并PR<br>检查通过条件：openharmony_ci测试通过+PR允许合入 | 任何人 |
| check dco | 可选 | DCO检查失败时，更新DCO信息后，人工触发检查DCO<br>检查通过条件：已签署DCO+PR所有提交均包含Signed-off-by信息且检查通过。可参考[DCO FAQ](https://gitee.com/openharmony/docs/blob/master/zh-cn/contribute/FAQ.md)处理 | PR创建人 |
| check dco | 可选 | DCO检查失败时，更新DCO信息后，人工触发检查DCO<br>检查通过条件：已签署DCO+PR所有提交均包含Signed-off-by信息。可参考[DCO FAQ](https://gitee.com/openharmony/docs/blob/master/zh-cn/contribute/FAQ.md)处理 | PR创建人 |
| static-check | 可选 | 静态检查失败时，手工触发静态检查，仅用于单独验证，不影响最终构建结果 | PR创建人 |
| assign [@gitee_id] | **必选** | committer分配检视人员，命令中如果不指定gitee_id，committer安排自己为检视人员 | committer |
| lgtm | 可选 | PR检视人员无检视意见、认可PR时，评论该命令提醒Committer该PR可以合入；如果是Committer评论该命令，可以直接合入相关的PR | 通过assign命令分配的检视人员PR检视人员<br>committer |
| check comment | 可选 | 提交检视意见后，评论该该命令提醒PR创建人修改检视意见 | PR检视人员<br>committer |
| code review | 可选 | 代码仓没有配置测试门禁时，使用该命令提醒代码仓Committer进行代码检视 | PR创建人 |
| assign [@gitee_id1 @gitee_id2...] | 可选 | Committer分配检视人员，可以通过空格分割来指定多个检视人员；如果命令中不指定gitee_id，committer安排自己为检视人员。<br>分配的检视人员需参与检视，给出检视意见，然后评论命令check comment提醒PR提交人处理；无检视意见时，评论命令lgtm，提醒committer审核处理 | Committer |
| unassign @gitee_id | 可选 | 取消分配检视人员 | Committer |
| lgtm | 可选 | 如果使用assign命令分配了检视人员，PR检视人员无检视意见时，需评论该命令提醒committer可以合入对应的PR。分配多个检视人员时，需要每个检视人员都评论命令lgtm，才会提醒committer可以合入对应的PR | 通过assign命令分配的检视人员PR检视人员<br>Committer |
| check comment | 可选 | 如果检视人员提交了检视意见，需评论该命令来提醒PR创建人修改检视意见 | PR检视人员<br>Committer |
| code review | 可选 | 如果代码仓没有配置测试门禁，需评论该命令来提醒代码仓committer进行代码检视 | PR创建人 |
## Issue评论支持命令清单
| 评论输入命令 | 是否必选 | 使用场景 | 命令触发角色 |
| ------------- | ---- | ----------------------------------------------------------------------------------------------------------- | ---------------------- |
| close | 可选 | committer审核issue，认定为非问题、重复问题、评审不解决时，通过该命令告知issue提交人要关闭对应的issue。 | committer<br>仓库成员等审核人员 |
| check comment | 可选 | 审核人员认定issue缺少信息，评论需要补充的信息后，再评论命令，issue打回提交人补充信息。 | committer<br>仓库成员等审核人员 |
| check update | 可选 | 标签为waiting_on_author时，issue提交人补充信息后，通过评论该命令，CI Bot会把标签设置为waiting_for_assign（未分配责任人）或waiting_for_fix（已分配责任人） | issue提交人 |
| ------------- | ---- | ---------------------------------------------------------------------------------------------------------------- | ---------------------- |
| close | 可选 | Committer审核issue，认定为非问题、重复问题、评审不解决时，通过该命令告知issue提交人要关闭对应的issue。CI Bot会把issue标签设置为waiting_on_author | Committer<br>仓库成员等审核人员 |
| check comment | 可选 | 审核人员认定issue缺少信息，评论需要补充哪些信息后，再评论该命令，issue会打回给issue提交人补充信息。CI Bot会把issue标签设置为waiting_on_author | Committer<br>仓库成员等审核人员 |
| check update | 可选 | 标签为waiting_on_author时，issue提交人补充信息后，通过评论该命令，CI Bot会把issue标签设置为waiting_for_assign（未分配责任人）或waiting_for_fix（已分配责任人） | Issue提交人 |
## Pull Request标签说明
在PR检视审核过程中，CI Bot会为PR设置处理状态标签，用于标识处理阶段。处理阶段包含：PR提交人处理阶段，检视人员分配阶段，检视人员检视阶段，等待审核合入阶段和已合入阶段。
| 标签 | 标签说明 | 触发命令、条件 |
| ------------------ | ------------------------ | -------------------------------- |
| waiting_on_author | 需要贡献者修改检视意见、门禁未通过等。 | start build门禁失败<br>check comment |
| waiting_for_review | 等待Committer指定检视人员检视提交的PR | start build门禁成功 |
| ------------------ | ------------------------ | ------------------------------------------- |
| waiting_on_author | 需要贡献者修改检视意见或门禁未通过等。 | start build门禁失败<br>check comment |
| waiting_for_review | 等待Committer指定检视人员检视提交的PR | start build门禁成功<br>代码仓没有配置门禁时，评论code review |
| reviewing | 已分配检视人员，处于代码检视阶段 | assign [@gitee_id]分配检视人员 |
| waiting_for_merge | 检视人员无检视意见，已同意合入。 | 检视人员评论lgtm |
| merged | PR已经合并 | 审核者合入 |
......@@ -54,7 +55,7 @@
在issue检视审核过程中，CI Bot会为issue设置处理状态标签，用于标识处理阶段。处理阶段包含：issue提交人处理阶段，issue责任人分配阶段，Issue责任人修复阶段和已闭环阶段。
| 标签 | 标签说明 | 触发命令、条件 |
| ------------------ | -------------------------------------------- | ----------------------------------- |
| waiting_on_author | 需要Issue 提交人修改Issue，补充信息等；<br>需要Issue 提交人确认验收 | 审核者通过close命令返回提交人修改 |
| waiting_for_assign | 需求Issue审核者分配责任人处理Issue | 提交有效Issue后，CI Bot自动@仓库Committer提醒处理 |
| waiting_for_fix | issue在修复中 | committer分配了责任人，关联了pr |
| ------------------ | -------------------------------------------- | --------------------------- |
| waiting_on_author | 需要issue 提交人修改Issue，补充信息等；<br>需要issue 提交人确认验收 | 审核者通过close命令返回issue提交人修改 |
| waiting_for_assign | 需要issue审核者分配责任人处理issue | Issue提交人创建issue后，且创建时未指定责任人 |
| waiting_for_fix | issue在修复中 | Committer分配了责任人或关联了PR |
Markdown is supported
0% 或 .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑！
想要评论请 注册 或