CI持續集成系統環境--Gitlab+Gerrit+Jenkins完整對接

時間 2019-11-15

標籤持續集成系統環境 gitlab+gerrit+jenkins gitlab gerrit jenkins 完整對接欄目 Git 简体版

原文原文鏈接

近年來，因爲開源項目、社區的活躍熱度大增，進而引來持續集成（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便可（下文有介紹）
----------------------------------------------------------------------------------------------------------------------------------------html

1、基礎環境搭建（參開下面三篇文檔）
CI持續集成系統環境---部署gerrit環境完整記錄
 CI持續集成系統環境---部署Gitlab環境完整記錄
 CI持續集成系統環境---部署Jenkins完整記錄java

2、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。以下：python

在Gitlab上建立wangshibo用戶
而後在機器上生成wangshibo公鑰（先提早在機器上建立wangshibo用戶，跟上面同樣操做），而後將公鑰內容更新到Gitlab上（用wangshibo帳號登錄Gitlab）
用gerrit登錄Gitlab，新建group組爲dev-group，而後建立新項目test-project1（在dev-group組下，即項目的Namespace爲dev-group，將wangshibo用戶添加到dev-group組內，權限爲Reporter），具體以下截圖：mysql

建立的項目設置成Private即私有的，這樣普通用戶這它就只有pull權限，沒有push權限。linux

在test-project1工程裏建立文件，建立過程此處省略......
文件建立後，以下：android

在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 unexpectedlynginx

上面有報錯，由於普通用戶沒有直接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裏git

一樣的，將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.cngithub

設置SMTP的服務器地址，點擊「高級」web

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

 
         [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

 
         [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

 
         [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

 
         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

 
         [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最後完整配置以下：

 
         [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裏留有記錄。
----------------------------------------------------------------------------------------------------------------------------------
到此！
gerrit環境部署及其中遇到的一些問題，權限設置等已經收錄完成，但願對有用到gerrit的朋友們有所幫助！！

***************當你發現本身的才華撐不起野心時，就請安靜下來學習吧***************

閱讀原文

Gerrit+Jenkins搭建CI系統

In gerrit, the option --verified is missing from the 'gerrit review' command(code review verfied)

jenkins+gerrit+Git 搭建CI系統