参考链接：

• Gerrit官方文档: Gerritcodereview
• Github issue: Github

背景：

搭建了Openldap维护公司域账户信息，Gerrit用户验证接入了LDAP。
gerrit.config配置如下（信息请更新为各自公司节点）：

1
2
3
4
5

[ldap]
  server = ldap://ldap.example.com
  username = ldapuser
  accountBase = ou=people,dc=example,dc=com
  groupBase = ou=groups,dc=example,dc=com

业务需求：

公司特定合作伙伴 有 访问代码库 进行 联合开发的需求。

方案设计：

1. 在现有LDAP节点的基础上，增加一个ou（custom），用来维护合作伙伴账号；
2. 同步 这个ou（custom）的人员到Gerrit上。

配置Gerrit支持多ou user信息：

根据Gerrit官方文档：

1
2
3

ldap.accountBase
    Root of the tree containing all user accounts. This is typically of the form ou=people,dc=example,dc=com.
    This setting may be added multiple times to specify more than one root.

我们调整gerrit.config配置如下：

1
2
3
4
5
6

[ldap]
  server = ldap://ldap.example.com
  username = ldapuser
  accountBase = ou=people,dc=example,dc=com
  accountBase = ou=custom,dc=example,dc=com
  groupBase = ou=groups,dc=example,dc=com

然后重启Gerrit后，custom里面的人员也可以登录Gerrit了。

配置Gerrit支持多group信息：

方法和上面同步多个ou user信息相似，增加ldap.groupBase行即可。
根据Gerrit官方文档：

1
2
3

ldap.groupBase
    Root of the tree containing all group objects. This is typically of the form ou=groups,dc=example,dc=com.
    This setting may be added multiple times to specify more than one root.

关于LDAP group信息：

一般系统接入LDAP做账户验证，只需同步LDAP的user信息，不直接使用LDAP的group信息。
各个系统自行创建系统组进行人员权限管理，这样更加灵活。
同时，也不建议LDAP里面维护太多group，更加推荐LDAP轻量化使用。

Comment and share

背景

公司使用Gerrit作为代码托管平台。
Gerrit除了设置项目权限外，还提供了很好的code review功能。
下面分别简单介绍普通Git用法和code review用法

普通Git使用方法：

如上图所示：

Git仓库主要分为：本地仓库（各位clone到本机）和远端仓库（scm负责维护的，搭建在一台服务器上面）；

绝大多数的命令都不需要和远端的git仓库打交道，本地执行即可；

1
2
3
4

git clone :克隆一个远端git仓库到本地
git fetch：获取远端git仓库变化到本地仓库，并不会更改当前工作区文件
git pull：这个命令相当于：先执行git fetch 然后执行git merge变化到当前工作区
git push：将本地仓库的变化推送到远端git服务器

Code Review使用方法：

如上图所示：
使用Gerrit进行code review一言蔽之就是Gerrit加了个中间层；
本地仓库的变更执行git push提交到Gerrit；code reviewer可以在gerrit上面对本次提交进行review并给出评价；

管理员在review评估ok（至少有一个+2）后，在gerrit上面点击submit，会把本次变更推送到远端仓库。

PS:+1 +2 -1 -2 0不是数字意义！！！（两个reviewer都给了+1评论并不代表已经+2了）

原理解析：

为了实现上面所说的功能，gerrit引入了change_id和for空间；

我们执行git push到for空间；
如果大家的本地git config没有做过配置，那么咱们执行git push的完整命令是：
git push origin HEAD:refs/heads/master
推送当前本地最新代码到远端（origin）master分支

使用code review的话执行git push完整命令是：
git push origin HEAD:refs/for/master
推送当前本地最新代码到for空间的master分支供gerrit识别

PS：以上写的都是git原始命令供大家更好的理解，实际使用中可以简写！！！

Gerrit根据change-Id识别你的patch；

我们需要引入commit-msg钩子文件到本地代码库:
（这个是gerrit原生提供的通过scp命令实现）
在本地代码库下运行（将weilong.wang改成自己的用户名），执行一次即可
gitdir=$(git rev-parse –git-dir); scp -p -P 29418 weilong.wang@Gerrit_Server_Ip:hooks/commit-msg ${gitdir}/hooks/

commit-msg钩子的作用和使用：
1.Dev正常本地修改代码，git add，git commit 会自动在message后面增加算出一个唯一的change-id
例如： Change-Id: I45088f6b73bf53b62b2ee3b09c005952e9838548
2.如果本次patch提交到gerrit后，review不通过：本地修改代码， git add， git commit –amend
（更新新的修改到当前commit；同时可以修改commit message；不要对message的最后一行change-id做修改！！！）
接着push到gerrit：因为change-id并没有改变，所以还是同一个地方，patch set增长1

PS：建议合并最新版本代码到本地：使用git pull –rebase
如果使用git pull： merge点不自动产生change-id！！！

喜闻乐见简化配置：

根据上面的解释大家应该发现想使用gerrit进行code review还得手工做些事情：

1. git clone远端代码库到本地
2. 从远端服务器下载commit-msg钩子到本地仓库.git/hooks/目录
3. 每次都要本地git commit后执行git push origin HEAD:refs/for/master
4. 去gerrit上面添加code reviewers
   这并不是我想要的生活。。。

一劳永逸方法：

1. git clone远端代码库到本地
2. 从远端服务器下载commit-msg钩子到本地仓库.git/hooks/目录
3. 修改本地代码库config vi .git/config增加下面内容
   [remote “review_master”]
   url = 代码库地址
   push = HEAD:refs/for/master%r=weilong.wang@memblaze.com,r=dev1@memblaze.com
4. 本地git commit后执行git push review_master即可
   会自动提交到refs/for/master并增加weilong和dev1作为code reviewers;

PS： remote “review_master” 这个可以换成你喜欢的其他字符串；假如改成remote “haha” 那么最终push的时候执行 git push haha
PS： pushurl这个请自行替换成各位执行git clone的地址
PS： 自动添加code reviewers请自行替换成各位项目的同事

Comment and share

背景：

公司目前使用Gerrit作为代码库托管和Code review平台。 使用Jenkins作为自动化构建和持续集成平台。

流程设计：

1. Dev本地开发，然后上传patch到gerrit：

• 同时触发Jenkins CR_Job来做build
• 增加Code reviewers来做review

2. 再上述都成功的基础上，reviewer点击+2：

• 同时触发Jenkins Submit_Job来做build和test：
  • 如果成功，自动合并本次patch到代码库
  • 如果失败，返回-1

3. Nightly test Job：

• 每晚20:00触发，获取当前最新的代码进行build和test

测试分级：

• CR_Job:
  • 获取触发patch的代码，合并最新分支代码，进行build
  • 快速反馈，主要检查patch合并是否有冲突和build是否能跑通

• Submit_Job：
  • 获取触发patch的代码，合并最新的分支代码，进行build和测试
  • 根据每天代码提交次数来确定时间和test cases

• Nightly_Job：
  • 获取当前最新代码进行build和test
  • 一般跑12h，第二天早上出测试报告邮件

软件环境：

• Jenkins插件：

搭建步骤：

1. 安装配置Jenkins Gerrit Trigger插件：官方wiki
   
2. 安装Jenkins Multijob plugin：官方wiki
   
3. 配置CR_Job:
   
4. 配置Submit_job:
   
5. 配置Nightly_Job:
   

PS

1. 以上内容都是基于公司研发现状定制的，建议各位根据自己的情况进行定制。
2. 因为历史遗留原因，当前使用的版本比较旧。 例如如果升级到jenkins2.x版本的话pipeline就不需要借助插件来实现了。

Comment and share