近年来,由于开源项目、社区的活跃热度大增,进而引来持续集成(CI)系统的诞生,也越发的听到更多的人在说协同开发、敏捷开发、迭代开发、持续集成和单元测试这些拉风的术语。然而,大都是仅仅听到在说而已,国内也很少有公司能有完整的 CI 体系流程。反之一些开源项目都有完整的 CI体系,比如openstack。
为了实现代码托管->代码审核->代码发布的一套自动化流程,我特意在IDC服务器上部署了Gitlab+Gerrit+Jenkins对接环境,以下记录了操作过程:
----------------------------------------------------------------------------------------------------------------------------------------
1)Gitlab上进行代码托管
在gitlab上创建的项目设置成Private,普通用户对这个项目就只有pull权限,不能直接进行push
Git自带code review功能
强制Review :在 Gitlab 上创建的项目,指定相关用户只有Reporter权限,这样用户没有权限使用git push功能,只能git review到Gerrit 系统上,Jenkins在监听Gerrit上的项目事件会触发构建任务来测试代码, Jenkins 把测试结果通过 ssh gerrit 给这个项目打上 Verified (信息校验)成功或失败标记,成功通知其它人员 Review(代码审核) 。
Gitlab保护Master 分支:在 Gitlab 上创建的项目可以把 Master 分支保护起来,普通用户可以自己创建分支并提交代码到自己的分支上,没有权限直接提交到Master分支,用户最后提交申请把自己的分支 Merge 到 Master ,管理员收到 Merge 请求后, Review 后选择是否合并。
可以将gitlab和gerrit部署在两台机器上,这样gitlab既可以托管gerrit代码,也可以作为gerrit的备份。
因为gitlab和gerrit做了同步,gerrit上的代码会同步到gitlab上。
这样即使gerrit部署机出现故障,它里面的代码也不会丢失,可以去gitlab上拿。
2)Gerrit审核代码
Gerrit是一款被Android开源项目广泛采用的code review(代码审核)系统。普通用户将gitlab里的项目clone到本地,修改代码后,虽不能直接push到代码中心 ,但是可以通过git review提交到gerrit上进行审核。gerrit相关审核员看到review信息后,判断是否通过,通过即commit提交。然后,gerrit代码会和gitlab完成同步。
grrit的精髓在于不允许直接将本地修改同步到远程仓库。客户机必须先push到远程仓库的refs/for/*分支上,等待审核。
gerrit上也可以对比代码审核提交前后的内容状态。
3)jenkins代码发布
当用户git review后,代码通过jenkins自动测试(verified)、人工review 后,代码只是merge到了Gerrit的项目中,并没有merge到 Gitlab的项目中,所以需要当 Gerrit 项目仓库有变化时自动同步到Gitlab的项目仓库中。Gerrit 自带一个 Replication 功能,同时我们在安装 Gerrit 时候默认安装了这个 Plugin,通过添加replication.config 给 Gerrit即可(下文有介绍)
----------------------------------------------------------------------------------------------------------------------------------------

一、基础环境搭建(参开下面三篇文档)
CI持续集成系统环境---部署gerrit环境完整记录
CI持续集成系统环境---部署Gitlab环境完整记录
CI持续集成系统环境---部署Jenkins完整记录

二、Gitlab+Gerrit+Jenkins的对接
1)Gitlab配置
gitlab上的管理员账号是gerrit,邮箱是gerrit@xqshijie.cn
创建了一个普通账号wangshibo,邮箱是wangshibo@xqshijie.cn
[root@115]# su - gerrit
[gerrit@115 ~]$ ssh-keygen -t rsa -C gerrit@xqshijie.cn         //产生公私钥
[gerrit@115 ~]$ cat ~/.ssh/id_rsa.pub 
将上面gerrit账号的公钥内容更新到Gitlab上。
使用gerrit账号登陆Gitlab,点击页面右上角的Profile Settings - 点击左侧的SSH Keys小钥匙图标 - 点击Add SSH Key。
在Key对应的输入框中输入上段落$cat .ssh/id_rsa.pub显示的公钥全文,点击Title,应该会自动填充为gerrit@xqshijie.cn。如下:

在Gitlab上创建wangshibo用户
然后在机器上生成wangshibo公钥(先提前在机器上创建wangshibo用户,跟上面一样操作),然后将公钥内容更新到Gitlab上(用wangshibo账号登陆Gitlab)
用gerrit登陆Gitlab,新建group组为dev-group,然后创建新项目test-project1(在dev-group组下,即项目的Namespace为dev-group,将wangshibo用户添加到dev-group组内,权限为Reporter),具体如下截图:

创建的项目设置成Private即私有的,这样普通用户这它就只有pull权限,没有push权限。

在test-project1工程里创建文件,创建过程此处省略......
文件创建后,如下:

在linux系统上登录wangshibo账号下,克隆工程test-project1.git,测试权限
[root@115]# su - wangshibo
[wangshibo@115 ~]$ git clone git@103.10.86.30:dev-group/test-project1.git
Initialized empty Git repository in /home/wangshibo/test-project1/.git/
remote: Counting objects: 15, done.
remote: Compressing objects: 100% (9/9), done.
remote: Total 15 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (15/15), done.
[wangshibo@115 ~]$ cd ~/test-project1/
[wangshibo@115 ~]$ git config --global user.name 'wangshibo'
[wangshibo@115 ~]$ git config --global user.email 'wangshibo@xqshijie.cn'
[wangshibo@115 ~]$ touch testfile
[wangshibo@115 ~]$ git add testfile
[wangshibo@115 ~]$ git commit -m 'wangshibo add testfile'
[wangshibo@115 ~]$git push 
GitLab: You are not allowed to push code to this project.
fatal: The remote end hung up unexpectedly

上面有报错,因为普通用户没有直接push的权限。需要先review到gerrit上进行审核并commit后,才能更新到代码中心仓库里。
2)Gerrit配置
在linux服务器上切换到gerrit账号下生成公私钥
[gerrit@115]$ ssh-keygen -t rsa -C gerrit@xqshijie.cn
将id_rsa.pub公钥内容更新到gerrit上(管理员gerrit账号登陆)的SSH Public Keys里

同样的,将gerrit的其他两个普通账号wangshibo和jenkins也在linux服务器上生产公私钥,邮箱分别是wangshibo@xqshijie.cn和jenkins@xqshijie.cn
并将两者的公钥id_rsa.pub内容分别更新到各自登陆的gerrit的SSH Public Keys里
3)Jenkins配置
Jenkins系统已经创建了管理员账户jenkins并安装了Gerrit Trigger插件和Git plugin插件
在“系统管理”->“插件管理"->”可选插件"->搜索上面两个插件进行安装
使用jenkins账号登陆jenkins,进行Jenkins系统的SMTP设置 (根据具体情况配置)
“主页面->系统管理->系统设置”,具体设置如下:
首先管理员邮件地址设置成jenkins@xqshijie.cn

设置SMTP的服务器地址,点击“高级”

jenkins@xqshijie.cn的密码要确认填对,然后测试邮件发送功能,如果如下出现successfully,就成功了! 点击“保存”

接下来设置Gerrit Trigger

Add New Server : Check4Gerrit
勾选 Gerrit Server With Default Configurations

具体设置如下:
设置好之后,点击“Test Connection”,如果测试连接出现如下的Success,即表示连接成功!
点击左下方的Save保存。

-----------------------------------------------------------------------------------------
如果上一步在点击“Test Connection”测试的时候,出现下面报错:
解决办法:
管理员登录gerrit
Projects->List->All-Projects
Projects->Access
Global Capabilities->Stream Events 点击 Non-Interactive Users
添加 Jenkins@zjc.com 用户到 ‘Non-Interactive Users’ 组
-----------------------------------------------------------------------------------------

4)Gerrit 和 Jenkins 整合
让Gerrit支持Jenkins
如果安装Gerrit时没有或者没有选择添加Verified标签功能[‘lable Verified’],需要自己添加。
如下是手动添加Verified标签功能的设置(由于我在安装Gerrit的时候已经选择安装Verified标签功能了,所以下面橙色字体安装操作可省略)
[如果在安装gerrit的时候没有选择安装这个标签功能,就需要在此处手动安装下。具体可以登陆gerrit,ProjectS->list->All-Projects->Access->Edit->Add Permission 看里面是否有Verfied的选项]
# su - gerrit
$ git init cfg; cd cfg
$ git config --global user.name 'gerrit'
$ git config --global user.email 'gerrit@xqshijie.cn'
$ git remote add origin ssh://gerrit@103.10.86.30:29418/All-Projects
$ git pull origin refs/meta/config
$ vim project.config
[label "Verified"]
    function = MaxWithBlock
    value = -1 Fails
    value = 0 No score
    value = +1 Verified
$ git commit -a -m 'Updated permissions'
$ git push origin HEAD:refs/meta/config
$ rm -rf cfg

用gerrit管理员账号登录Gerrit
现在提交的Review请求只有Code Rivew审核,我们要求的是需要Jenkins的Verified和Code Review双重保障,在 Projects 的 Access 栏里,针对 Reference: refs/heads/ 项添加 Verified 功能,如下如下:
Projects -> List -> All-Projects
Projects -> Access -> Edit -> 找到 Reference: refs/heads/* 项 -> Add Permission -> Label Verified -> Group Name 里输入 Non-Interactive Users -> 回车 或者 点击Add 按钮 -> 在最下面点击 Save Changes 保存更改。
(注意:提前把jenkins用户添加到Non-Interactive Users组内)
权限修改结果如下:

截图如下:

添加Verified后的权限如下

Gitlab上设置test-project1工程
前面我们在Gitlab上搭建了一个 test-project1 的工程,普通用户是没有办法去 push 的,只能使用 git review 命令提交. 而 git review 命令需要 .gitreview 文件存在于项目目录里。
用 gerrit用户添加.gitreview 文件
[root@115]# su - gerrit
[gerrit@115]$ git clone git@103.10.86.30:dev-group/test-project1.git
[gerrit@115]$ cd test-project1
[gerrit@115]$ vim .gitreview

1
2
3
4
[gerrit]
host=103.10.86.30
port=29418
project=test-project1.git

添加.gitreview到版本库
[gerrit@115]$git add .gitreview
[gerrit@115]$git config --global user.name 'gerrit'
[gerrit@115]$git config --global user.email 'gerrit@xqshijie.cn'
[gerrit@115]$git commit .gitreview -m 'add .gitreview file by gerrit.'
[gerrit@115]$git push origin master

用gerrit用户添加.testr.conf 文件
Python 代码我使用了 testr,需要先安装 testr 命令
[root@115]# easy_install pip
[root@115]# pip install testrepository

在 test-project1 这个项目中添加 .testr.conf 文件
[root@115]#su - gerrit
[gerrit@115]$cd test-project1
[gerrit@115]$vim .testr.conf

1
2
3
4
5
6
7
[DEFAULT]
test_command=OS_STDOUT_CAPTURE=1
OS_STDERR_CAPTURE=1
OS_TEST_TIMEOUT=60
${PYTHON:-python} -m subunit.run discover -t ./ ./ $LISTOPT $IDOPTION
test_id_option=--load-list $IDFILE
test_list_option=-list

提交到版本库中
[gerrit@115]$git add .testr.conf
[gerrit@115]$git commit .testr.conf -m 'add .testr.conf file by gerrit'
[gerrit@115]$git push origin master

Gerrit上设置 test-project1工程
在Gerrit上创建 test-project1 项目
要知道review是在gerrit上,而gerrit上现在是没有项目的,想让gitlab上的项目能在gerrit上review的话,必须在gerrit上创建相同的项目,并有相同的仓库文件.
用gerrit用户在 Gerrit 上创建 test-project1 项目
[root@115]# su - gerrit
[gerrit@115]$ ssh-gerrit gerrit create-project test-project1 (gerrit环境部署篇里已经设置好的别名,方便连接gerrit) 
登陆gerrit界面,发现test-project1工程已经创建了。(这种方式创建的项目是空的)

clone --bare Gitlab上的仓库到 Gerrit (gerrit上的项目最好是从gitlab上git clone --bare过来,并且项目不要为空)
因为gerrit用户无访问gitlab的权限。所以要先看是否gerrit用户下已经存在了id_rsa密钥,如果没有则创建,然后把公钥加入到gitlab的管理员账户上(因为后面Gerrit系统还会有个复制git库到 Gitlab的功能需要管理员权限)(这个测试环境,gitlab和gerrit的管理员我用的都是gerrit,所以秘钥也是共用)
[gerrit@115]$ cd /home/gerrit/gerrit_site/git/            //即登陆到gerrit安装目录的git下
[gerrit@115 git]$ rm -fr test-project1.git
[gerrit@115 git]$ git clone --bare git@103.10.86.30:dev-group/test-project1.git             //创建并将远程gitlab上的这个项目内容发布到gerrit上
[gerrit@115 git]$ ls
All-Projects.git test-project1.git
[gerrit@115 git]$ cd test-project1.git/ 
[gerrit@115 git]$ ls                                 //即test-project1工程和gerrit里默认的All-Projects.git工程结构是一样的了
branches config description HEAD hooks info objects packed-refs refs

同步 Gerrit的test-project1 项目到 Gitlab 上的 test-project1 项目目录中
当用户git review后,代码通过 jenkins 测试、人工 review 后,代码只是 merge 到了 Gerrit 的 test-project1 项目中,并没有 merge 到 Gitlab 的 test-project1 项目中,所以需要当 Gerrit test-project1 项目仓库有变化时自动同步到 Gitlab 的 test-project1 项目仓库中。
Gerrit 自带一个 Replication 功能,同时我们在安装 Gerrit 时候默认安装了这个 Plugin。

现在只需要添加一个 replication.config 给 Gerrit
[gerrit@115]$ cd /home/gerrit/gerrit_site/etc/
[gerrit@115]$ vim replication.config

1
2
3
4
5
6
7
[remote "test-project1"]
projects = test-project1
url = git@103.10.86.30:dev-group/test-project1.git
push = +refs/heads/*:refs/heads/*
push = +refs/tags/*:refs/tags/*
push = +refs/changes/*:refs/changes/*
threads = 3

设置gerrit用户的 ~/.ssh/config
[gerrit@115]$ vim /home/gerrit/.ssh/config

1
2
3
Host 103.10.86.30:
       IdentityFile ~/.ssh/id_rsa
       PreferredAuthentications publickey

在gerrit用户的~/.ssh/known_hosts 中,给103.10.86.30 添加 rsa 密钥
[gerrit@115]$ sh -c "ssh-keyscan -t rsa 103.10.86.30 >> /home/gerrit/.ssh/known_hosts"
[gerrit@115]$ sh -c "ssh-keygen -H -f /home/gerrit/.ssh/known_hosts"
----------------------------------------------特别注意----------------------------------------------
上面设置的~/.ssh/config文件的权限已定要设置成600
不然会报错:“Bad owner or permissions on .ssh/config“
----------------------------------------------------------------------------------------------------
重新启动 Gerrit 服务
[gerrit@115]$/home/gerrit/gerrit_site/bin/gerrit.sh restart

Gerrit 的复制功能配置完毕
在 gerrit 文档中有一个 ${name} 变量用来复制 Gerrit 的所有项目,这里并不需要。如果有多个项目需要复制,则在 replication.config 中添加多个 [remote ….] 字段即可。务必按照上面步骤配置复制功能。

在 Jenkins 上对 test-project1 项目创建构建任务
Jenkins上首先安装git插件:Git Plugin
登陆jenkins,“系统管理”->“管理插件”->“可选插件”->选择Git Pluin插件进行安装

Jenkins上创建项目
添加 test-project1工程

下面添加url:http://103.10.86.30:8080/p/test-project1.git
添加分支:origin/$GERRIT_BRANCH

如下:

构建Excute Shell,添加如下脚本
cd $WORKSPACE 
[ ! -e .testrepository ] && testr init 
testr run

测试
linux系统上用wangshibo账号提交一个更改
用wangshibo登录
删除目录 test-project1
克隆 test-project1 工程
进入 test-project1 目录
添加文件、提交
git review 增加 review 到Gerrit
[root@115]# su - wangshibo
[wangshibo@115]$ rm -rf test-project1/
[wangshibo@115]$ git clone git@103.10.86.30:dev-group/test-project1.git
[wangshibo@115]$ cd test-project1/
[wangshibo@115]$ touch testfile
[wangshibo@115]$ git add testfile
[wangshibo@115]$ git commit -m "wangshibo add this testfile"

[wangshibo@115]$ git review                         //提交review代码审核请求
The authenticity of host '[103.10.86.30]:29418 ([103.10.86.30]:29418)' can't be established.
RSA key fingerprint is 83:ff:31:e8:68:66:6d:49:29:08:91:aa:ef:36:77:3e.
Are you sure you want to continue connecting (yes/no)? yes
Creating a git remote called "gerrit" that maps to:
ssh://wangshibo@103.10.86.30:29418/test-project1.git
Your change was committed before the commit hook was installed
Amending the commit to add a gerrit change id
remote: Resolving deltas: 100% (1/1)
remote: Processing changes: new: 1, refs: 1, done 
To ssh://wangshibo@103.10.86.30:29418/test-project1.git
* [new branch] HEAD -> refs/publish/master
----------------------------------------小提示----------------------------------------
安装git-review
[root@115]# git clone git://github.com/facebook/git-review.git 
[root@115]# cd git-review 
[root@115]# python setup.py install
[root@115]# pip install git-review==1.21
[root@115]# yum install readline-devel
--------------------------------------------------------------------------------------

代码审核处理
用gerrit管理员账号登录 Gerrit ,点击"All“->”Open“-> 打开提交的review
打开后就能看见jenkins用户已经Verified【原因下面会提到】。
然后点击Review进行审核

由于上面已经配置了gerrit跟jenkins的对接工作,所以当git review命令一执行,jenkins上的test-project1工程的测试任务就会自动触发
如下:如果任务自动执行成功了,就说明jenkins测试通过,然后jenkins会利用ssh连接gerrit并给提交的subject打上verified信息校验结果,然后审核人员再进行review。

所以用gerrit管理员登陆后发现,jenkins已经通过了Verified,如下

注意:
等到jenkins上Verified通过后,即看到下图右下角出现“Verified +1 jenkins"后
才能点击"Code-Review+2",如下:

然后点击“Submit",提交审核过的代码

再次查看,review请求已被审核处理,并且已经Merged合并了!

最后登录 Gitlab查看 test-project1 工程,可以看到新增加文件操作已经同步过来了

注意:在审核人员进行review和submit操作前,要先等到jenkins测试并通过ssh方式连上gerrit给相应提交审核的subjects带上Verified通过后才能进行。(gitlab+gerrit+jenkins环境配置后,提交到gerrit上审核的subjects的review人员中会默认第一个是jenkins,jenkins有结果并verified后,其他人员才能veriew和submit。也就是说当开发人员使用git review上报gerrit进行code review后,jenkins会自动触发测试任务,通过后会在gerrit的subject审核界面显示verified结果,当显示的结果是“verified +1 jenkins“后就可以进行Review和submit了,最后同步到gitlab中心仓库。)

查看同步日志:
可以在gerrit服务器上查看replication日志:
[gerrit@115 logs]$ pwd
/home/gerrit/gerrit_site/logs
[gerrit@115 logs]$ cat replication_log
.........................
[2016-07-14 15:30:13,043] [237da7bf] Replication to git@103.10.86.30:dev-group/test-project1.git completed in 1288 ms
[2016-07-14 15:32:29,358] [] scheduling replication test-project1:refs/heads/master => git@103.10.86.30:dev-group/test-project1.git
[2016-07-14 15:32:29,360] [] scheduled test-project1:refs/heads/master => [03b983c0] push git@103.10.86.30:dev-group/test-project1.git to run after 15s
[2016-07-14 15:32:44,360] [03b983c0] Replication to git@103.10.86.30:dev-group/test-project1.git started...
[2016-07-14 15:32:44,363] [03b983c0] Push to git@103.10.86.30:dev-group/test-project1.git references: [RemoteRefUpdate[remoteName=refs/heads/master, NOT_ATTEMPTED, (null)...dda55b52b5e5f78e2332ea2ffcb7317120347baa, srcRef=refs/heads/master, forceUpdate, message=null]]
[2016-07-14 15:32:48,019] [03b983c0] Replication to git@103.10.86.30:dev-group/test-project1.git completed in 3658 ms

----------------------------------------------------------------------------------------------------
关于jenkins上的结果:
如上,在服务器上wangshibo账号下
git review命令一执行,即代码审核只要一提出,Jenkins 就会自动获取提交信息并判断是否verified
如下,当jenkins上之前创建的工程test-project1执行成功后,那么jenkins对提交到gerrit上的review请求
就会自动执行Verified(如上)

----------------------------------------------注意----------------------------------------------
有个发现:
jenkins上测试并返回给gerrit上提交的subject打上Verified信息核实通过的标签后,会将代码拿到自己本地相应工程的workspace目录下
这里的jenkins代码路径是:/usr/local/tomcat7/webapps/jenkins/workspace/test-project1

不过值得注意的是,jenkins拿过来的代码只是每次git review修改前的代码状态
可以把这个当做每次代码修改提交前的备份状态
即:代码修改后,在gerrit里面审核,commit后同步到gitlab,修改前的代码状态存放在jenkins里面
-----------------------------------------------------------------------------------------------
手动安装gerrit插件
[gerrit@115r ~]$ pwd
/home/gerrit
[gerrit@115r ~]$ ls
gerrit-2.11.3.war gerrit_site

进行插件安装,下面安装了四个插件
[gerrit@115r ~]$ java -jar gerrit-2.11.3.war init -d gerrit_site --batch --install-plugin replication
Initialized /home/gerrit/gerrit_site
[gerrit@115r ~]$ java -jar gerrit-2.11.3.war init -d gerrit_site --batch --install-plugin reviewnotes
Initialized /home/gerrit/gerrit_site
[gerrit@115r ~]$ java -jar gerrit-2.11.3.war init -d gerrit_site --batch --install-plugin commit-message-length-validator
Initialized /home/gerrit/gerrit_site
[gerrit@115r ~]$ java -jar gerrit-2.11.3.war init -d gerrit_site --batch --install-plugin download-commands
Initialized /home/gerrit/gerrit_site

查看plugins目录,发现已经有插件了
[gerrit@115r ~]$ cd gerrit_site/plugins/
[gerrit@115r ~]$ ls
commit-message-length-validator.jar download-commands.jar replication.jar reviewnotes.jar

查看安装了哪些插件
[gerrit@115r ~]$ ssh-gerrit gerrit plugin ls

Name                                    Version                Status                 File
-------------------------------------------------------------------------------
commit-message-length-validator v2.11.3 ENABLED commit-message-length-validator.jar
download-commands v2.11.3 ENABLED download-commands.jar
replication v2.11.3 ENABLED replication.jar
reviewnotes v2.11.3 ENABLED reviewnotes.jar

或者登陆gerrit也可查看

------------------------------------------------注意------------------------------------------------
gerrit手动同步代码到gitlab中心仓库上
[gerrit@115r ~]$ ssh-gerrit gerrit --help          //查看帮助,发现gerrit COMMAND --help可查找命令帮忙
[gerrit@115r ~]$ ssh-gerrit replication start --help          //查看replication同步命令的用法

replication start [PATTERN ...] [--] [--all] [--help (-h)] [--url PATTERN] [--wait]

PATTERN : project name pattern
-- : end of options
--all : push all known projects
--help (-h) : display this help text
--url PATTERN : pattern to match URL on
--wait : wait for replication to finish before exiting

[gerrit@115r ~]$ ssh-gerrit replication start --all                    //同步所有工程
-------------------------------------------------------------------------------------------------------

重载replication的同步服务
[gerrit@115r ~]$ ssh-gerrit gerrit plugin reload replication
如果报错:fatal: remote plugin administration is disabled

解决办法:
在/home/gerrit/gerrit_site/etc/gerrit.config文件里添加下面内容:
[plugins]
allowRemoteAdmin = true

然后重启gerrit服务即可:
[gerrit@115r ~]$ /home/gerrit/gerrit_site/bin/gerrit.sh restart
Stopping Gerrit Code Review: OK
Starting Gerrit Code Review: OK

----------------------------------------------------------------------
ssh-gerrit是别名
[gerrit@115r ~]$ cat ~/.bashrc 
# .bashrc

# Source global definitions
if [ -f /etc/bashrc ]; then
. /etc/bashrc
fi
alias ssh-gerrit='ssh -p 29418 -i ~/.ssh/id_rsa 103.10.86.30 -l gerrit' 
# User specific aliases and functions
-------------------------------------------------------------------------------------------

多个工程在Gitlab上可以放在不同的group下进行管理
如下面两个工程(多个工程,就在后面追加配置就行)
dev-group /test-project1
app/xqsj_android

多个工程的replication
[gerrit@Zabbix-server etc]$ cat replication.config

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
[remote "test-project1"]
projects = test-project1
url = git@103.10.86.30:dev-group/test-project1.git
push = +refs/heads/*:refs/heads/*
push = +refs/tags/*:refs/tags/*
push = +refs/changes/*:refs/changes/*
threads = 3
 
[remote "xqsj_android"]
projects = xqsj_android
url = git@103.10.86.30:app/xqsj_android.git
push = +refs/heads/*:refs/heads/*
push = +refs/tags/*:refs/tags/*
push = +refs/changes/*:refs/changes/*
threads = 3

然后在每个代码库里添加.gitreview和.testr.conf 文件,
注意.gitreview文件里的项目名称

按照上面同步配置后,Gerrit里面的代码就会自动同步到Gitlab上,包括master分支和其他分支都会自动同步的。
如果,自动同步失效或者有问题的话,可以尝试手动同步(下面有提到)

另外:为了减少错误,建议在配置的时候,gitlab和gerrit里的账号设置成一样的,共用账号/邮箱/公钥
gerrit默认的两个project:All-Project和All-Users绝不能删除!!

--------------------------------------------去掉jenkins测试的方式---------------------------------------------

如果gerrit不跟jenkins结合,不通过jenkins测试并返回verified核实的方式,可以采用下面的代码审核流程(必须先对提交的审核信息进行verified核实,然后再进行代码的review审核,最后submit提交):
[去掉上面gerrit和jenkins对接设置,即关闭jenkins服务(关停对应的tomcat应用),gerrit的access授权项verified里删除“Group Non-Interactive Users”(在这个组内踢出jenkins用户),并删除gerrit上的jenkins用户]

1)上传代码者(自己先verified核实,然后通知审核者审核)
修改代码,验证后提交到 Gerrit 上。
代码提交后登陆 Gerrit,自己检查代码(重点看缩进格式跟原文件是否一致;去掉红色空格部分;修改内容是否正确;命名是否有意义;注释内容是否符合要求等)。
自己检查没问题后,点 “Reply”按钮,在“Verified”中 +1,在“Code Review”中 +1,并点“Post“
在”Reviewer”栏中,点击”Add"添加审核者 [如果不添加审核者,上传者自己也可以审核并完成提交。注意:只有Review是+2的时候,才能出现submit的提交按钮]
如果代码审核没有通过,请重复步骤1,2,3。

流程截图:
代码提交后,上传者自行登陆gerrit,找到提交的subject,点击"Reply"

2)审核者
收到邮件通知后登陆 Gerrit,审核代码。
如果审核通过,点 “Reply”按钮,在“Verified”中 +1,在“Code Review”中 +2,并点“Post”,最后点击“Submit“提交!
如果代码审核没有通过,点 “Review”按钮,在“Code Review”中 -2,写好评论后,点“Post”。

流程截图:
如上,subject的owner添加审核者后,审核者登陆gerrit进行review
点击“Reply"

这样,就完成了一个代码的审核全部过程!
登陆gitlab,就会发现gerrit上审核通过并提交后的代码已经同步过来了!

注意:
如上的设置,在gerrit里授权的时候:
Revified权限列表里添加“Project Owners“(-1和+1)和审核者组(-1和+1)
Review权限列表里添加“Project Owners“和审核者组(都要设置-2和+2)

附授权截图:

------------------------------------让非管理员用户也有gitweb访问权限--------------------------------------

发现在gerrit与gitweb集成后,默认情况下,只有gerrit的管理员才有gitweb的访问权限,普通用户点击gitweb链接显示404错误。
最后发现使用gitweb需要有【refs/*】下所有的read权限和【refs/meta/config】的read权限!
默认情况下:
【refs/*】下的read权限授予对象是:Administrators和Anonymous Users(所有用户都是匿名用户,这个范围很大,已默认包括所有用户)

【refs/meta/config】的read权限授予对象是:Administrators和Project Owners
如想要比如上面的xqsh-app组内的用户能正常访问gitweb,那么就在【refs/meta/config】分支下授予这个组的Allow权限即可!!
截图如下:

使用普通用户wangshibo(在xqsj-app组内)登陆gerrit,发现能打开xqsj_android项目的gitweb超链接访问了

---------------------------------------------------------------------------------------------------------
后续应开发人员的要求:Gitlab+gerrit+jenkins环境下,gerrit有几个细节,都是需要设置好的:
1)项目A的开发人员对于除A以外的项目没有访问权限;
2)每个开发人员应该有+2和submit,以及创建分支的权限;
3)给teamleader配置force push的权限;

设置方案:
第1个要求:
在gerrit里面设置read权限,即"refs/*"下的"Read"权限。
先保持将All-Projects默认权限不变!
然后重新Edit项目A的权限去覆盖掉All-Projects继承过来的这个权限(下面会提到)
如下截图(前面的Exclusive一定要打勾,覆盖效果才能生效)

其实,开发人员是没有必要开通gitlab账号!只要gerrit提前和gitlab做好同步对接工作,那么直接设置好gerrit权限,开发人员可直接通过ssh方式登陆gerrit进行代码操作(git clone代码,然后修改,提交审核,自动同步等)所以,只需要给开发人员开通gerrit账号即可!
<如下,通过ssh方式连接gerrit上的项目,进行git clone代码或git pull操作等>
如下:
按照gerrit上的ssh连接方式clone项目代码(前提是把本地服务器的公钥上传到gerrit上)
可以复制下图中的clone或clone with commit-msg hook地址在本地进行代码clone

第2个要求:
a)在gerrit里面设置,创建组比如xqsj-app,然后把这个组添加到gerrit界面相对应项目的”access“授权里的“refs/heads/*”->Label Code-Review内,以及Submit内,这样就保证每个开发人员有+2和submit权限
b)将上面创建的xqsh-app组添加到gerrit界面相对应项目的”access“授权里的“refs/heads/*”->“Create Reference”内,这样就能保证每个开发人员有创建分支的权限了。

第3个要求:
创建teamleader组,比如xqsj-app-teamleader,将这个组添加到A项目编辑的下面两个权限里,去覆盖从All-Projects继承过来的权限!
“refs/heads/*”->"Push"
“refs/meta/config”->“Push”
这两个地方地Push权限最好只赋给Administrators管理员和teamleader组,这样就保证了每个teamleader有force push的权限了。
(注意,勾上在后面的“force push”前的小框,如下截图)
这样,xqsj-app-teamleader组内的用户通过ssh方式连接gerrit,git clone下载代码,修改后可直接git push了(不需要review审核)

在这里还讲一下下面/refs/for/refs/*的两个Push权限,这个All-Projects里默认是赋予Registered Users注册用户的
那么,在给项目新编辑权限去覆盖的时候,最好把权限赋予对象改成项目所在的组!
(如上面所说的,修改代码push的中心仓库的权限就只关联到上面两个权限,跟这个无关)

如下:
将wangshibo用户拉到xqsj-app-teamleader组内,上面已经设置了“Force Push”权限,所以wangshibo用户连接gerrit
修改后的代码可直接push了!然后同步到gitlab!
[wangshibo@115 ~]$ git clone ssh://wangshibo@103.10.86.30:29418/xqsj_android
Initialized empty Git repository in /home/wangshibo/www/xqsj_android/.git/
remote: Counting objects: 653, done
remote: Finding sources: 100% (653/653)
remote: Total 653 (delta 180), reused 653 (delta 180)
Receiving objects: 100% (653/653), 2.86 MiB, done.
Resolving deltas: 100% (180/180), done.
[wangshibo@Zabbix-server www]$ ls
xqsj_android
[wangshibo@115 ~]$ cd xqsj_android/
[wangshibo@115 ~]$ vim testfile                  //修改代码
[wangshibo@115 ~]$ git add testfile
[wangshibo@115 ~]$ git commit -m "222"
[master 87a02b7] 222
1 files changed, 1 insertions(+), 0 deletions(-)
[wangshibo@115 ~]$ git push             //直接push即可!如果wangshibo不在teamleader组内,就不能直接push了,就只能git review审核了!
Counting objects: 5, done.
Delta compression using up to 32 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 261 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1)
remote: Processing changes: refs: 1, done 
To ssh://wangshibo@103.10.86.30:29418/xqsj_android
1840a0c..87a02b7 master -> master

这样,一个项目的开发人员在修改代码并提交gerrit后,就可以指定有相应权限的人员进行review和submit了。
另外注意:
修改gerrit上创建的group组名或增删等操作,可以直接在服务器上的mysql里面操作。

---------------------------------------------------特别注意-------------------------------------------------------
如果要想让新建立的项目不继承或不完全继承All-Project项目权限,可以自己重新修改或添加权限,以便去覆盖掉不想继承的权限!
这里以我测试环境的一个项目xqsj_android做个例子说明:

首先在gerrit上创建一个组xqsj_android,将wangshibo普通用户放到这个组内!
1)想要wangshibo登陆gerrit后,只能访问它所在的项目xqsj_android
设置方法:
上面已讲到,即将All-Projects的access里的"refs/*"-"Read"权限只给Administors(就只保留管理员的这个read权限),这样,project工程就只有管理员权限才能访问到了!
<因为其他新建的项目默认都是继承All-Projects权限的,设置上面的Read权限只保留Administors后,其他的项目如果不Edit自己的权限去覆盖继承过来的权限,那么这些项目内的用户登陆后,都访问不了这些项目的>

然后再在xqsj_android项目上创建Reference权限,去覆盖继承过来的All-Project权限!
特别注意下面的“Exclusive”,这个一定要勾上!!勾上了才能生效,才能覆盖All-Project项目的权限。
截图如下:

如上截图,发现“refs/*”的“Read”权限除给了管理员Administrators,也添加了xqsj_android组,由于wangshibo在这个组内,
所以wangshibo登陆gerrit后,有访问xqsj_android项目的权限。

注意:
All-Projects默认的权限最好都保持不变,不要动!
新建项目有的权限可以自行Edit编辑,然后去覆盖All-Projects继承过来的权限(新建的Reference时,后面的Exclusive一定要在前面的小方框内打上勾,这样覆盖才能生效!)

下面贴一下本人线上的gerrit项目修改后的权限:

------------------------------------------------------------------------------------------------------
git clone下载代码,可以根据gitlab上的ssh方式克隆,也可以根据gerrit上的ssh方式克隆代码。
具体采用哪种,根据自己的需要判断。

注意:当审核未通过打回时,我们再修改完成之后,执行:
git add 文件名
git commit --amend ##注意会保留上次的 change-id ,不会生成新的评审任务编号,重用原有的任务编号,将该提交转换为老评审任务的新补丁集
git review
-------------------------------------------------------------------------------------------------------
如果想让某个用户只有读权限,没有写权限。即登陆gerrit后只能查看,不能进行下载,上传提交等操作
解决:
1)创建一个read的用户组,然后将这个只读用户拉到这个read组内

2)在相应项目的access授权里添加这个用户组,如下,只需添加下面两个地方的Read部分即可:
其中,“refs/meta/config”里的Read授权,可以让用户查看到gitlab

----------------------------------------------添加tag权限----------------------------------------------
如上,已经给teamleader用户组内的用户授权直接push了,但是后面发现teamleader里的用户只能直接push推送代码到gerrit里,
而不能直接push推送tag标签到gerrit里!
这是因为上面的push权限是针对“refs/heads/*”和“refs/meta/config”设置的
而push tag需要针对“refs/tags/*”进行设置
所以,需要添加refs/tags/*部分的设置,并给与push权限,如下:

--------------------------------------------------------------------------------------------------------------

gerrit完整迁移
将远程gerrit上的代码迁移到本地新的gerrit上
要求:
远程gerrit里的代码分支和提交记录都要迁移过来,【即Git仓库迁移而不丢失log】(push的时候使用--mirrot镜像方式即可)
流程:
1)将远程gerrit的项目比如A进行git clone –bare克隆裸版本库到本地
2)在本地新的gerrit上创建同名项目A(创建空仓库)
3)然后将克隆过来的A项目内容git push --mirror到本地新gerrit上的项目A内
git push --mirror git@gitcafe.com/username/newproject.git (新gerrit上项目A的访问地址)
这种方式就能保证分支和提交记录都能完整迁移过来了!!!

----------------------------------------------------------------------------------------------------------
后续对项目代码进行操作,在登陆gerrit审核后,查看代码(对比代码提交前后的内容)时候出现了一个错误,具体如下:
其实代码review通过并submit后,查看代码有两种方式:
1)通过项目的gitweb查看。当然,这种方法查看也比较繁琐,没有下面的第(2)种方法查看起来方便

2)通过submit提交后的界面(也就是merged合并后的界面),如下点击红色方框内的审核代码进行查看:

但是点击上面红色方框内的审核代码进行查看,出现如下报错:

经过排查,发现造成这个报错的原因是由于nginx的反代配置有误造成的,如下:
proxy_pass http://103.10.86.30:8080/;
需要将上面的反向代理改为:
proxy_pass http://103.10.86.30:8080;
也就是说代理后的url后面不能加"/",这个细节在前期配置的时候没有注意啊!!

gerrit.conf最后完整配置如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
[root@localhost vhosts]# pwd
/usr/local/nginx/conf/vhosts
[root@localhost vhosts]# cat gerrit.conf
server {
listen 80;
server_name localhost;
 
#charset koi8-r;
    #access_log  /var/log/nginx/log/host.access.log  main;
location / {
          auth_basic              "Gerrit Code Review";
          auth_basic_user_file    /home/gerrit/gerrit_site/etc/passwords;
          proxy_pass              http://103.10.86.30:8080;
          proxy_set_header        X-Forwarded-For $remote_addr;
          proxy_set_header        Host $host;
    }
}
 
[root@localhost vhosts]# /usr/local/nginx/sbin/nginx -s reload

对比代码在review前后的状态:修改了哪些内容(右边部分是review修改后的代码状态。点击右边"Patch Set 1"后面的图标,可以下载或修改代码)

-------------------------------------------------------------------------------------------------------------
以上部署环境中,有一个不安全的地方,就是用户提交代码后,自己对代码都有review最终审核权限,即"用户自己review提交审核-自己+1/+2审核-自己submit",这样设计不是很合理!
现在做下调整:
用户自己review提交代码后,自己只有Code-Review +2的权限和Submit,Verfied +1的权限统一交由专门的审核人员去处理,比如teamleader组。
这样,代码审核的过程:
1)用户自己review提交代码审核
2)teamleader组内人员收到审核后,通过Verfied +1审核
3) 用户自己通过Code-Review +2审核
4)用户自己Submit提交,Merged合并处理。
具体的权限设置调整如下:

----------------------------------------------------------------------------------------------------------------------------------
有一个问题:
如果给某个账号开了push权限,他在代码commit提交后,就可以直接git push上传到gerrit里面,可以不经过git review审核提交的代码。如下授权截图:

但是这样直接git push的话,在gerrit界面的Merged处就追踪不到这个账号提交代码的记录了,也就是说,只有经过review审核提交的代码记录才能在gerrit界面的Merged下追踪到!如下:

如上所说,那么直接push提交代码的记录该怎么追踪到呢?
莫慌!
其实不管是push直接提交代码的记录,还是经过review审核提交的代码记录,都可以在gitweb的log里追踪到的!

虽然授权了push权限,但是也还是可以使用git review命令进行审核的,这样在gerrit界面的Merged里也能追踪到提交记录了。
如果是直接git push的,那么提交代码的时候就会直接绕过review审核了,这样当然不会在gerrit的Merged里留有记录。

Gitlab+Gerrit+Jenkins完整对接的更多相关文章

  1. [原创]CI持续集成系统环境--Gitlab+Gerrit+Jenkins完整对接

    近年来,由于开源项目.社区的活跃热度大增,进而引来持续集成(CI)系统的诞生,也越发的听到更多的人在说协同开发.敏捷开发.迭代开发.持续集成和单元测试这些拉风的术语.然而,大都是仅仅听到在说而已,国内 ...

  2. CI持续集成系统环境--Gitlab+Gerrit+Jenkins完整对接

    原文地址https://www.cnblogs.com/kevingrace/p/5651447.html 近年来,由于开源项目.社区的活跃热度大增,进而引来持续集成(CI)系统的诞生,也越发的听到更 ...

  3. [原创]CI持续集成系统环境--Gitlab+Gerrit+Jenkins完整对接https://www.cnblogs.com/kevingrace/p/5651447.html

      近年来,由于开源项目.社区的活跃热度大增,进而引来持续集成(CI)系统的诞生,也越发的听到更多的人在说协同开发.敏捷开发.迭代开发.持续集成和单元测试这些拉风的术语.然而,大都是仅仅听到在说而已, ...

  4. gitlab+gerrit+jenkins持续集成框架

    1.持续集成之gitlab+gerrit+jenkins 1.1. GitLab 1.1.1. 简介 GitLab 是一个使用使用Ruby on Rails搭建的,用于仓库管理系统的开源项目.使用Gi ...

  5. 配置gitlab gerrit jenkins

    配置gerrit 在gerrit创建jenkins用户 把jenkins用户加入Non-Interactive的组中 Projects -> List -> All-Projects Pr ...

  6. gitlab+gerrit+jenkins

    gitlab-repo 指在 gitlab 上的代码库, gerrit-repo 指在 gerrit 上的代码库: 从 gitlab-repo 上获取代码 本地修改, 提交 push 到 gerrit ...

  7. gitlab gerrit jenkins CI/CD环境集成

    http://blog.csdn.net/williamwanglei/article/details/38498465

  8. 部署gerrit环境完整记录【转】

    开发同事提议在线上部署一套gerrit代码审核环境,废话不多说,部署gerrit的操作记录如下:提前安装好java环境,mysql环境,nginx环境测试系统:centos6.5下载下面三个包,放到/ ...

  9. gitlab & gerrit & git & repo & jenkins

    Omnibus GitLab documentation(中文安装说明) 在自己的服务器上部署 GitLab 社区版->较为全面 GIT & REPO & GERRIT (三) ...

随机推荐

  1. python基础知识--条件判断和循环

    一.输入输出 python怎么来接收用户输入呢,使用input函数,python2中使用raw_input,接收的是一个字符串,输出呢,第一个程序已经写的使用print,代码入下: 1 name=in ...

  2. SpringMVC(8) - 处理器映射

    在以前的Spring版本中,用户需要在Web应用程序上下文中定义一个或多个HandlerMapping bean,以将传入的Web请求映射到适当的处理器.通过引入带注解的控制器,就不需要像之前那样定义 ...

  3. POJ 2112: Optimal Milking【二分,网络流】

    题目大意:K台挤奶机,C个奶牛,每台挤奶器可以供M头牛使用,给出奶牛和和机器间的距离矩阵,求所有奶牛走最大距离的最小值 思路:最大距离的最小值,明显提示二分,将最小距离二分之后问题转化成为:K台挤奶机 ...

  4. POJ 1080 Human Gene Functions 【dp】

    题目大意:每次给出两个碱基序列(包含ATGC的两个字符串),其中每一个碱基与另一串中碱基如果配对或者与空串对应会有一个分数(可能为负),找出一种方式使得两个序列配对的分数最大 思路:字符串动态规划的经 ...

  5. 【BFS+优先级队列】Rescue

    https://www.bnuoj.com/v3/contest_show.php?cid=9154#problem/I [题意] 给定一个n*m的迷宫,A的多个小伙伴R要去营救A,问需要时间最少的小 ...

  6. Tsinghua OJ Zuma

    Description Let's play the game Zuma! There are a sequence of beads on a track at the right beginnin ...

  7. BZOJ1573: [Usaco2009 Open]牛绣花cowemb

    求半径d<=50000的圆(不含边界)内n<=50000条直线有多少交点,给直线的解析式. 一开始就想,如果能求出直线交点与原点距离<d的条件,那么从中不重复地筛选即可.然而两个kx ...

  8. msp430入门编程27

    msp430中C语言开发工具调试程序 msp430入门学习 msp430入门编程

  9. MITM Proxy环境搭建

    MITM_Proxy环境搭建 环境要求 系统环境要求: Ubuntu 14.04 x64,CentOS 7 x64以上版本系统(建议使用xubuntu 14.04 x64,稳定硬件要求低) Pytho ...

  10. PHP错误处理函数set_error_handler()的用法[转载]

    定义和用法 set_error_handler() 函数设置用户自定义的错误处理函数. 该函数用于创建运行时期间的用户自己的错误处理方法. 该函数会返回旧的错误处理程序,若失败,则返回 null. 语 ...