点击蓝字 ╳ 关注我们
1、新流程能解决什么问题
先回顾下社区Issue和PR处理时存在的问题痛点。经常关注社区的开发者会注意到,社区待处理的Issue和PR数量多的时候,处理速度会变得缓慢。导致Issue和PR不能有效处理的原因主要有:从社区贡献者一侧来分析,社区Issue和PR未规范提交,比如Issue描述不规范,缺少详细描述和验证步骤等关键信息;PR门禁编译失败、格式检测失败、门禁检查失败,DCO失败、未参考检视意见修改等,这些因素都会导致请求无法被处理而不能被合入。从社区贡献流程侧来分析,社区Issue和PR处理流程也存在一些改进点,比如当前缺少Issue责任人精准分配;缺少机制分配PR检视人,PR处理阶段不清晰;缺少处理超期时的主动提醒功能等;对超期的Issue和PR,系统不能自动处理等。
OpenHarmony社区为解决上述问题,对Issue和PR处理流程进行了优化,主要包含:
●标记状态标签,明确处理阶段责任人
通过标记状态标签识别处理责任阶段、明确处理人。如果Issue和PR提交不规范,会有状态标签显示当前处理责任人为提交人;如果提交的PR通过门禁测试,等待审核检视,当前处理责任人为Committer;如果已分配检视人员,当前处理责任人就是代码检视人员等。
●主动提醒责任人处理待办事项
CI Bot会发邮件每日提醒责任人处理名下的待办事项。强烈建议社区贡献者订阅Issue和PR的状态变化通知,这样就会接收系统的自动提醒。
●超期问题自动处理
基于规则,对于一些可以自动处理的情况进行分析,进行自动化处理。比如,对于验收中的Issue,如果长期未确认,系统会自动进行关闭;对于门禁未通过等情况导致不符合合入标准的PR,超过一定时间,也会自动关闭。
OpenHarmony社区通过这些流程优化来提升Issue和PR处理效率,下文会详细介绍流程的优化点和具体使用方法。
2、新流程介绍
以PR提交与审核流程为例,如图1所示,我们按状态标签进行讲解,开发者们也可以参考
https://gitee.com/openharmony/community/blob/master/zh/infrastructure/build_command.md
PR提交人(社区贡献者)创建PR后,PR的标签为Waiting_On_Author,表示当前的责任人为PR提交人。CI Bot会提醒PR提交人及时处理该PR。如果PR提交人长时期未处理该PR,CI Bot会进行自动关闭。
如果PR提交人触发门禁构建,构建失败后,PR的标签依旧为Waiting_On_Author状态。如果检视人员或Committer审核人员提交了检视意见,需要社区贡献者去查看、修复,PR的标签会被标记为Waiting_On_Author状态。
当PR提交人评论命令start build(仓库配置门禁时使用该命令,如果未配置门禁,请使用code review命令),并且门禁构建成功后,PR的状态标签替代为Waiting_For_Review状态,表示当前的责任人为Committer审核人员,需要由Committer分配检视人员。CI Bot可以每日邮件定时提醒待办事项,催促Committer分配检视人员。
Committer可以通过命令assign [@gitee_id1 @gitee_id2...]分配检视人员。使用该命令时,Committer可以通过空格分隔来指定多个检视人员;如果命令中不指定gitee_id,Committer则安排自己为检视人员。分配检视人员后,PR的状态标签变换为Reviewing状态,表示当前的责任人为代码检视人员。
分配的检视人员需参与检视,给出检视意见,然后评论命令check comment提醒PR提交人处理;无检视意见时,评论命令lgtm,提醒Committer审核处理。
当所有检视人员均对分配的PR没有检视意见时,并在PR评论区评论命令lgtm后,CI Bot会提醒Committer去审核该PR。此时,PR的状态标签变换为Waiting_For_Merge状态。
对于Waiting_For_Merge状态标签的PR, 当Committer审核通过后,PR的状态标签会自动变换为Merged状态,表示该PR成功合入。
3、流程处理实例讲解
本节以Pull Request处理流程为例,按处理阶段分别进行讲解。
当PR提交人提交一个PR后,CI Bot会自动评论,如下图所示。根据提示,如果代码已经开发完毕,PR提交人在PR评论区评论start build来触发门禁。在触发门禁前状态标签为Waiting_On_Author,当前的处理责任人为PR提交人。
如果审核检视人员为PR提交检视建议后,PR的状态标签变为Waiting_On_Author,需要PR提交人处理建议,优化修复提交的代码。当处理完毕,重新推送代码后,需要重新触发门禁。
注意:如果代码仓没有配置门禁,提示的内容稍有不同,需要评论的命令是code view。
在门禁通过后,PR的状态标签会替换为Waiting_For_Review状态,如下图所示。此后,该PR的处理责任人为代码仓的Committer。Committer会负责分配检视人员或者审核该PR。
当一个PR处于Waiting_For_Review状态时,Committer可以使用assign命令分配给检视人员进行检视,如下图所示。命令assign的具体用法,可以参考上一小节图片中的操作提示。当分配完毕检视人员,PR的状态标签会替换为Reviewing状态,当前的处理责任人为分配的检视人员。
如果检视人员发现检视的PR存在问题,提出检视意见后,需要评论下check comment通知PR提交人根据检视意见进行修改。PR的状态标签会替代为Waiting_On_Author状态,当前的处理责任人为PR提交人。
如果PR不存在问题,检视人员认为可以合入,需要评论下lgtm(即:look good to me)通知Committer审核合入该PR。PR的状态标签会替代为Waiting_For_Merge状态,当前的处理责任人为Committer。
4、CI Bot待办提醒
5、小结
本文对OpenHarmony社区贡献流程优化点进行了介绍,包含新支持的一系列交互命令和状态标签,以及CI Bot的每日待办事项邮件、自动超期处理等。如有疑问,欢迎随时来社区反馈。
原文标题:10分钟快速掌握OpenHarmony社区贡献新流程
文章出处:【微信公众号:OpenAtom OpenHarmony】欢迎添加关注!文章转载请注明出处。
-
鸿蒙
+关注
关注
57文章
2301浏览量
42668 -
OpenHarmony
+关注
关注
25文章
3629浏览量
16030
原文标题:10分钟快速掌握OpenHarmony社区贡献新流程
文章出处:【微信号:gh_e4f28cfa3159,微信公众号:OpenAtom OpenHarmony】欢迎添加关注!文章转载请注明出处。
发布评论请先 登录
相关推荐
评论