CI持续集成系统环境--Gitlab+Gerrit+Jenkins完整对接——转近年来，由于开源项目、社区的活跃热度大增，进而引来持续集成（CI）系统的诞生，也越发的听到更多的人在说协同开发、敏捷开发、迭代开发、持续集成和单元测试这些拉风的术语。然而，大都是仅仅听到在说而已，国内也很少有公司能有完整的 CI 体系流程。 由于感兴趣，也查阅了一些资料，专门在测试机上进行了一番部署。结合Gitlab+Gerrit+Jenkins,实现代码托管->代码审核->代码发布的一套流程。 （1）Gitlab上进行代码托管 在gitlab上创建的项目设置成Private，普通用户对这个项目就只有pull权限，不能直接进行push Git自带code review功能 Gitlab 保护 Master 分支：在 Gitlab 上创建的项目可以把 Master 分支保护起来，普通用户可以自己创建分支并提交代码到自己的分支上，没有权限直接提交到 Master 分支，用户最后提交申请把自己的分支 Merge 到 Master ，管理员收到 Merge 请求后， Review 后选择是否合并。 可以将gitlab和gerrit部署在两台机器上，这样gitlab既可以托管gerrit代码，也可以作为gerrit的备份。 （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即可（下文有介绍） 下面对自己部署的Gitlab+Gerrit+Jenkins环境结合做一梳理： 一、基础环境搭建 http://www.cnblogs.com/kevingrace/p/5624122.html http://www.cnblogs.com/kevingrace/p/5651402.html http://www.cnblogs.com/kevingrace/p/5651427.html 二、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 Initialized empty Git repository in /home/wangshibo/test-project1/.git/ [wangshibo@115 ~]$ cd ~/test-project1/ GitLab: You are not allowed to push code to this project. 上面有报错，因为普通用户没有直接push的权限。需要先review到gerrit上进行审核并commit后，才能更新到代码中心仓库里。 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里 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
具体设置如下： 设置好之后，点击“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’ 组 ****************************************************************************************************************
Gerrit 和 Jenkins 整合让 Gerrit 支持 Jenkins 如果安装Gerrit时没有或者没有选择添加Verified标签功能[‘lable Verified’]，需要自己添加。 【如果在安装gerrit的时候没有选择安装这个标签功能，就需要在此处手动安装下。具体可以登陆gerrit，ProjectS->list->All-Projects->Access->Edit->Add Permission 看里面是否有Verfied的选项】 #su - gerrit [label "Verified"] function = MaxWithBlock value = -1 Fails value = 0 No score value = +1 Verified $ git commit -a -m 'Updated permissions' $ rm -rf cfg 用gerrit管理员账号登录Gerrit现在提交的Review请求只有Code Rivew审核，我们要求的是需要Jenkins的Verified和Code Review双重保障，在 Projects 的 Access 栏里，针对 Reference: refs/heads/ 项添加 Verified 功能，如下如下： Projects -> List -> All-Projects 《提前把jenkins用户添加到Non-Interactive Users组内》 权限修改结果如下
截图如下：
添加Verified后的权限如下
Gitlab上设置test-project1工程 前面我们在Gitlab上搭建了一个 test-project1 的工程，普通用户是没有办法去 push 的，只能使用 git review 命令提交. 而 git review 命令需要 .gitreview 文件存在于项目目录里。 用 gerrit用户添加.gitreview 文件 [root@115]#su - gerrit [gerrit] 添加.gitreview到版本库 用 gerrit用户添加.testr.conf 文件 Python 代码我使用了 testr，需要先安装 testr 命令 在 test-project1 这个项目中添加 .testr.conf 文件 提交到版本库中 Gerrit上设置 test-project1工程 在 Gerrit 上创建 test-project1 项目 用 gerrit用户在 Gerrit 上创建 test-project1 项目 [root@115]# su - gerrit 登陆gerrit界面，发现test-project1工程已经创建了。【这种方式创建的项目是空的】
clone –bare Gitlab 上的仓库到 Gerrit 《gerrit上的项目最好是从gitlab上git clone --bare过来，并且项目不要为空》 [gerrit@115]$ cd /home/gerrit/gerrit_site/git/ 【即登陆到gerrit安装目录的git下】 [gerrit@115 git]$ ls 同步 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用户的 ~/.ssh/config [gerrit@115]$ vim /home/gerrit/.ssh/config Host 103.10.86.30: 在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" <<<<<<<<<<<<<<<<<<<<<<<<特别注意>>>>>>>>>>>>>>>>>>>>>>>> 上面设置的~/.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
测试linux系统上用wangshibo账号提交一个更改 用wangshibo登录 [root@115]# su - wangshibo [wangshibo@115]$ git review 提交review代码审核请求 *********************小提示************************************************ 安装git-review [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 ......................... [2016-07-14 15:30:13,043] [237da7bf] Replication to git@103.10.86.30:dev-group/test-project1.git completed in 1288 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 进行插件安装，下面安装了四个插件 [gerrit@115r ~]$ java -jar gerrit-2.11.3.war init -d gerrit_site --batch --install-plugin replication 查看plugins目录，发现已经有插件了 查看安装了哪些插件 [gerrit@115r ~]$ ssh-gerrit gerrit plugin ls Name Version Status File 或者登陆gerrit也可查看
<<<<<<<<<<<<<<<<<<注意>>>>>>>>>>>>>>>>>>>> gerrit手动同步代码到gitlab中心仓库上 [gerrit@115r ~]$ ssh-gerrit gerrit --help 【查看帮助，发现gerrit COMMAND --help可查找命令帮忙】 replication start [PATTERN ...] [--] [--all] [--help (-h)] [--url PATTERN] [--wait] PATTERN : project name pattern [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] 然后重启gerrit服务即可： [gerrit@115r ~]$ /home/gerrit/gerrit_site/bin/gerrit.sh restart ********************************************** <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< # Source global definitions ************************************************* 多个工程在Gitlab上可以放在不同的group下进行管理 如下面两个工程（多个工程，就在后面追加配置就行） dev-group /test-project1 多个工程的replication [gerrit@Zabbix-server etc]$ cat replication.config [remote "xqsj_android"] 然后在每个代码库里添加.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用户》》 上传代码者（自己先verified核实，然后通知审核者审核） 流程截图： 代码提交后，上传者自行登陆gerrit，找到提交的subject，点击"Reply"
审核者 流程截图： 如上，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错误。 默认情况下： 【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超链接访问了
********************************************************* 后续应开发人员的要求： gerrit有几个细节，都是需要设置好的： 设置方案： 在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个要求： 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 这样，一个项目的开发人员在修改代码并提交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项目的权限。
注意： 下面贴一下本人线上的gerrit项目修改后的权限：
------------------------------------------------------------------------------------------------------------------------- git clone下载代码，可以根据gitlab上的ssh方式克隆，也可以根据gerrit上的ssh方式克隆代码。 具体采用哪种，根据自己的需要判断。 注意：当审核未通过打回时，我们再修改完成之后，执行： ************************************************************************************************ 解决： （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”设置的
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< gerrit完整迁移 将远程gerrit上的代码迁移到本地新的gerrit上 流程： 这种方式就能保证分支和提交记录都能完整迁移过来了！！！ <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 后续对项目代码进行操作，在登陆gerrit审核后，查看代码（对比代码提交前后的内容）时候出现了一个错误，具体如下： 其实代码review通过并submit后，查看代码有两种方式： （1）通过项目的gitweb查看。当然，这种方法查看也比较繁琐，没有下面的第（2）种方法查看起来方便！！
（2）通过submit提交后的界面（也就是merged合并后的界面），如下点击红色方框内的审核代码进行查看：
但是点击上面红色方框内的审核代码进行查看，出现如下报错：
解决措施： 发现使用80端口登陆后，再在后面加上8080端口，这样查看代码就正常了！ 尝试很多调试办法，苦于无解！ 最后没办法，又做了nginx的rewrite跳转，即访问http://ip，自动跳转到http://ip:8080 在nginx的vhost/gerrit.conf配置文件中，添加下面红色部分的配置（即rewrite跳转配置）： server { #charset koi8-r; location ~ ^/(.*) { 重启nginx服务后，访问gerrit跳转到8080端口的url。（即先80反向代理到8080请求，然后再rewrite跳转到指定url） 这样设置后访问gerrit，查看代码就没有那个报错了！ 但是按照上面nginx里添加rewrite跳转后，也有个问题： 就是浏览器缓存清理后，再次登陆时就会报错“用户认证失败！”（因为登陆时http://ip就跳到了http://ip:8080了，跟nginx认证用的80端口不一致） 所以，临时解决办法还是： 先http://ip登陆，登陆成功后再在ip后面加8080端口，这样就能保证登陆和查看代码都不冲突了。 具体解决方案，等待后续有时间了再研究了~~~~
对比代码在review前后的状态：修改了哪些内容
------------------------------------------------------------------------------------------------------------------------------------------------------ 以上部署的环境中，有一个不安全的地方，就是每个用户提交代码后，自己对代码都有review最终审核权限，即"用户自己review提交审核-自己+1/+2审核-自己submit"，这样设计不是很合理！ 现在做下调整： 这样，代码审核的过程： 具体的权限设置调整如下：
------------------------------------------------------------------------------------------------------------------------------------------------------ 有一个问题：
但是这样直接git push的话，在gerrit界面的Merged处就追踪不到这个账号提交代码的记录了，也就是说，只有经过review审核提交的代码记录才能在gerrit界面的Merged下追踪到!如下：
如上所说，那么直接push提交代码的记录该怎么追踪到呢？
淡然虽然授权了push权限，但是也还是可以使用git review命令进行审核的，这样在gerrit界面的Merged里也能追踪到提交记录了。 ------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
|
来自： ala咪s > 《SCM_gerrit》
