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名来查询
按项目来查询
