仓库合并平台checker开发文档

checker接入流程:

其实checker的接入也不需要做特别多的事情,只要对平台有基本了解,并且新开发的checker能增加测试的覆盖度,就可以了
1. 确定你将开发的checker的名字,然后由平台管理员在ci上建立对应的checker项目
2. 就可以进入checker开发阶段了

平台事件触发过程:

调用流程图

  • rr-hook-review-created
    • Review创建时会触发此ci项目
  • rr-hook-review-retriggered
    • retrigger 是指在review创建后,发现了rpa存在问题需要立即修复,rpa修复后由平台管理员重新触发checker的过程(类似于cr上的为同一个review重新提交补丁的过程)
    • Review平台执行retrigger时会触发此ci项目
  • rr-hook-review-all
    • Review created 和 Retrigger 事件都会触发此ci项目(一般的checker只需要关注此项目即可
  • rr-hook-review-merge-request
    • Review的合并动作被触发后,触发此项目

checker开发过程中,其实也没有太多约束的东西,原则上是不要把TOKEN泄露也就差不多合格了↖(^ω^)↗

下面简单说一下开发过程会用到的一些知识点

上游项目

调试阶段使用rr-hook-review-testrr-hook-review-test传给下游的是一个专门用于调试的review,并且需要手动触发来模拟hook过程。而rr-hook-review-all为真实项目,由平台自动触发。如果开发和调试完成了,可以将上游项目设置为rr-hook-review-all,如下图所示:
设置上游

上游文件

(现阶段)上游文件有两个:

  • params.env
    这个文件包含了review的基本参数,使用时直接source该文件即可
    现在params.env包含了:REVIEW_IDBASEBASE_CODENAMERPARPA_CODENAMEHOST_API,这几个参数

  • changelist.json
    该文件包含了关于本次review所有变更的包列表,包含包名,版本变化等信息

Project name也是和上面说的一样,调试阶段使用rr-hook-review-test项目,开发完成改成rr-hook-review-all即可

参数文件

回调测试结果

回调测试结果有两中方式:
1. submit “true” “nothing wrong”(推荐)
直接调用已经封装好的测试结果回调函数,接受两个参数:测试结果(true|false),描述,如下图所示:
submit-test
($BUILD_URL是jenkins的每一个job自带的环境变量,URL指向本次build执行的结果页面)

  1. 调用RepoReviewAPI测试结果接口

git管理你的测试脚本

如果你的checker不是一两句shell就可以搞定的话,强烈建议使用git管理你的脚本(不管你是托管到gerrit还是自己的其他仓库)
jenkins-git

RepoReview API

如果checker测试过程中需要获取Review的详细信息,请调用平台的其他API获取 Repository Review API

发表评论

电子邮件地址不会被公开。 必填项已用*标注