1、CI工作流程
当开发人员将本地Git仓库中的代码更新后,执行commit和push操作;该动作会生成一个事件,并触发Jenkins进行构建。如果开发人员在代码中加入和Junit或者testng测试用例,也会在构建过程中执行;构建完成后,jenkins会将构建的结果以Gerrit投票的方式传到Gerrit服务器上。项目Owner登录Gerrit Web UI,进行Code Review时会看到Jenkins构建的结果并进行code review。只有当构建成功,并且code review通过时,项目owner才会将代码合到主分支上,如果说jenkins上构建失败,则表示代码肯定有问题,Owner不用Code Review,直接通知开发检查代码并重新提交。
2、CI工作环境
Gerrit + Jenkins(安装Gerrit Trigger插件) +Git
Gerrit服务器:10.10.10.206
Jenkins服务器:10.10.10.202
两台服务器都安装了Git
3、CI配置
Gerrit上的配置
1、安装Label Verified
初次安装Gerrit时,在交互安装过程中,系统会问你是否安装Label Verified ,默认是不安装的。如果要搭建CI系统,这里需要选择安装。如果gerrit系统中没有安装这个东西,后期可以通过重装gerrit的方式再装上。重装gerrit和初次安装gerrit的命令一样:java -jar /path/to/gerrit.war /path/to/gerrit_dir。至于如何安装gerrit,请参考第一篇文档。
重装前,先停掉gerrit服务,交互安装过程中,很多步骤使用老的配置,默认即可。唯独提示是否安装Label Verified 时 选择y,表示安装。
2、在Gerrit服务器上为Jenkins服务器创建一个账号为jenkins。用该账号登录Gerrit Web UI,将该账号加入系统预设的Non-Interactive Users组。该组默认就已有监听Stream Events权限,Steam Events的原理是:Gerrit收到代码提交后,会以event的形式发给Jenkins,从而触发Jenkins自动构建。
3、为该账号设置SSH Key,即将Jenkins服务器的root账户下的公钥传到Gerrit上jenkins账号下的SSH Public Keys中,如果不知道如何设置,请参考前面的Gerrit用户配置文档。
4、为jenkins账号注册邮箱
5、设置jenkins用户的权限,注意设置权限,要对All-Projects进行设定
设置jenkins用户的read'权限
给jenkins用户设置Code Review权限和Verified权限,Code Review权限为-2~+1,当jenkins构建失败时,直接将gerrit投票结果设置为-2。
Jenkins上的配置
1、安装Gerrit Trigger插件
系统管理==>管理插件==>可选插件,搜索Gerrit Trigger,安装后重启Jenkins
2、配置Gerrit Trigger
系统管理==>Gerrit Trigger==>Add New Server
设置jenkins的对构建结果的一个gerrit投票值,构建失败则为-2,项目owner在不用code review了。项目如果构成成功则不表示代码一定OK,还是需要owner进行Code Review后在确认是否要merge
4、CI工作流程演示
这里我们还是用第4篇文档中的TEST项目来测试。
登录jenkins,创建一个maven项目
源码管理这里选择Git,Repository URL就是Gerrit Web上的为匿名用户提供的地址,注意把地址中的
git clone命令去掉,Jenkins服务器自身安装了git,集成了git环境。
注意:开发人员push的代码还没有merged,是保存在gerrit上的临时分支上的,所以我们要构建的话,应该去下载临时分支上的代码去构建。而不是下载$GERRIT_BRANCH上已经merge过的代码
Refspec:设置为refs/changes/*:refs/changes/*
Bracnes to build:设置为$GERRIT_REFSPEC,这个是git插件自带的宏,还有一个宏为$GERRIT_BRANCH,表示Gerrit上的分支。下面是Jenkins官方对这两个宏的解释:
To get the Git Plugin to download your change; set Refspec to $GERRIT_REFSPEC and the Choosing strategy to Gerrit Trigger. You may also need to set 'Branches to build' to $GERRIT_BRANCH. If this does not work for you set Refspec torefs/changes/*:refs/changes/* and 'Branches to build' to $GERRIT_REFSPEC.
Note: Be aware that $GERRIT_BRANCH and $GERRIT_REFSPEC are not set in the Ref Updated case. If you want to trigger a build, you can set Refspec and 'Branches to build' to $GERRIT_REFNAME.
只有这两个地方设置对,jenkins才能到gerrit上下载changes(即开发人员push的最新的代码)去构建。
构建触发器选择Gerrit event
Choose a server:选择前面配置的Gerrit Server
Trigger on:可以不配置,jenkins会默认选择 Patchset Created 和 Draft Published。表示开发人员只要push代码则触发构建,这是我们期望的。Change Merged表示当代码审核通过后,并且成功地Merge后才触发构建。Comment Added:这个选项可以自定义Code Review和Verified的值来触发构建,假如我这里Trigger on选择Comment Added,并且Code Review的值选择1,那么当项目管理员审核代码时,给的值为1,就会触发构建。
下面是官网的解释:
Draft Published: Sent when a change moves from draft state to new. (only available in version 2.5 or higher of Gerrit).
Patchset Created: Sent when a new patchset arrives on a change. Before version 2.6.0, this was the only event you could trigger on.
Change Merged: Sent when a change is merged on the Gerrit server.
Comment Added: Sent when a comment is added to a change. Which category and value to trigger on can be configured. The available categories can be configured in the server settings for the plugin.
Ref Updated: Sent when a ref is updated on the Gerrit server, i.e. someone pushes past code review.
Silent Mode:静默模式,即gerrit上做了code review和submit操作,Gerrit上对应的jenkins账号不发送邮件通知。
Gerrit Project:左边选择项目,右边选择分支,支持以下三种方式:
Plain: The exact name in Gerrit, case sensitive equality.
Path: ANT style pattern. Ex: "*/base/**"
RegExp:Regular expression.
我选择Path,后面写**,表示该项目所有分支。
构建后的操作,选择邮件通知
测试CI是否成功
用user2用户登录jenkins服务器10.10.10.202, 从Gerrit Web UI上clone TEST项目,
第一次clone TEST项目时,由于这个项目没有开发人员参与,所以TEST文件夹为空,这里的所有文件都是user2用户创建的。
pom.xml文件是构建maven项目必须的,cat pom.xml,可以看到我这里加入了testng的测试框架
在./src/test/java/com/carkey/testng/AppTest.java文件中写好了测试用例
创建代码文件,并将代码push到Gerrit服务器对应的项目仓库中
user2@localhost:~/TEST$ git add *
user2@localhost:~/TEST$ git commit -m "init"
[master 96c15a5] init
1 files changed, 1 insertions(+), 133 deletions(-)
rewrite code.sh (100%)
user2@localhost:~/TEST$ git push origin master:refs/for/master
Counting objects: 5, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 362 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: Processing changes: new: 1, refs: 1, done
remote:
remote: New Changes:
remote: http://10.10.10.206:8081/35 init
remote:
To ssh://user2@10.10.10.206:29418/TEST
* [new branch] master -> refs/for/master
登录Jenkins,看到项目构建时测试通过了,构建结果为Success。
用user2登录Gerrit Web UI,查看Jenkins的投票结果(也可以理解为构建结果),并邀请admin管理员进行Code Review
如下图可以看到jenkins构建成功了,Code-Review和Verified都是+1,这两个值是前面在Gerrit Trigger中配置的。
邀请admin进行Code-Review
admin用户进行Code Review。管理员根据jenkins的投票指导构建结果是Success。然后进行Code-Review,如果代码没有问题,则Code-Review+2,并Submit。
此时代码才会合到对应的分支上。
到这里CI工作流程就结束了。
5、Gerrit Trigger插件的的其他功能
安装这个插件后,在首页能看到Query and Trigger Gerrit Patches的功能
该功能可以查询Gerrit服务器上的所有项目的所有状态的事件
根据状态查询
根据项目查询
根据用户查询
根根据时间来查询:
6、build-metrics插件介绍
这个插件是全局性的插件,能查看所有项目的构建情况,包括成功、失败、不稳定、被终止等状态的构建。
安装:
这个插件的安装过程就不在详细描述,在插件管理--可选插件中直接搜索build-metrics,安装,重启jenkins即可
使用:
系统管理中,找到build-metrics,点击进去
根据时间和Job名来查询
按项目来查询