GitLab 是當前應用非常廣泛的 Git Hosting 工具，Jenkins 是非常牛逼的持續整合工具。儘管 GitLab 有內建的 GitLab CI，但它遠沒有 Jenkins 那麼強大好用。Jenkins 和 GitLab 在兩者的結合上，都提供了非常方便的工具。在我們向 GitLab push 程式碼，或執行其它一些操作時，GitLab 可以將這些時間通知給 Jenkins，trigger Jenkins 工程的構建自動執行。

要實現在向 GitLab push 程式碼時，自動 trigger Jenkins 工程執行構建動作，需要在 GitLab 和 Jenkins 的多個地方做配置：(1)、在 Jenkins 中安裝外掛；(2)、配置 GitLab 使用者；(3)、配置 Jenkins 伺服器；(4)、配置 Jenkins 工程；(5)、配置 GitLab 工程。

在 Jenkins 中安裝外掛

選擇 系統管理 -> 管理外掛 開啟外掛管理也頁面，如下圖：

在 可選外掛 中選擇 Gitlab Hook Plugin 和 GitLab Plugin 等外掛，然後點選下方的 直接安裝 按鈕安裝外掛：

建立測試工程

為了便於測試，這裡分別先在 Jenkins 和 GitLab 上建立測試工程。在 Jenkins Dashboard 主頁點選 新建任務，進入新建任務頁面：

在輸入框中輸入工程名，選擇 構建一個自由風格的軟體專案，然後點選左下角的 確定按鈕，進入工程配置頁面。

在工程配置頁面的 原始碼管理部分，輸入 GitLab repo 的 URL，如下圖：

如果是 https 形式的 URL，記得配置登入 GitLab 的使用者名稱和密碼，通過點選 Credentials 行最後面的 Add -> Jenkins 按鈕，在彈出的如下對話方塊中輸入使用者名稱和密碼：

Add 之後，在 Credentials 的下拉框中選擇這組使用者名稱和密碼。沒有新增 GitLab 的使用者密碼的話，Jenkins 報錯 —— 無法訪問 repo，如下圖：

隨後點選左下角的 儲存 按鈕，完成 Jenkins 工程的建立，並將它與 GitLab 的工程關聯起來。

配置 GitLab 使用者

建立一個使用者或選擇一個已有使用者，用來讓 Jenkins 和 GitLab API 互動。這個使用者將需要是全域性的管理員或新增進每個組／工程，並作為成員。需要開發者許可權來報告構建狀態。這是由於，當使用了 'Merge when pipeline succeeds' 功能時，成功的構建狀態可以觸發合併。GitLab Plugin 的一些功能可能需要其它的一些許可權。比如，有一個選項用於在構建成功時，接受 merge request。使用這一功能需要 developer，master 或 owner 級的許可權。

選擇 Settings -> Account：

拷貝其中的 Private token，稍後在配置 Jenkins 伺服器時會用到。

配置 Jenkins 伺服器

需要配置 Jenkins 伺服器來與 GitLab 伺服器通訊。

在 Jenkins 中，選擇 系統管理 -> 系統設定，在系統設定中找到 GitLab 的部分：

在 Connection name 後的輸入框中輸入連線名稱，在 Gitlab host URL 後的輸入框中輸入 GitLab 伺服器的 URL 地址。點選 Credentials 行最後面的 Add -> Jenkins 按鈕，彈出如下對話方塊，在 Kind 後的下拉列表中選擇 GitLab API token，並把上一步拷貝的 Private token 貼上到 API token 後面的輸入框中。隨後在 Credentials 的下拉框中選擇 GitLab API token。

配置 Jenkins 工程

開啟 Jenkins 工程的配置頁面，找到 構建觸發器 的部分，勾選 Build when a change is pushed to GitLab 那一行：

需要記下 Build when a change is pushed to GitLab 那一行中，GitLab CI Service URL: 後面的 URL，後面在配置 GitLab 工程時需要用到。

還要點開右下角的 高階：

隨後點選右下角的 Generate 按鈕，生成 Secret token，儲存這裡生成的 Secret token，它同樣將用於後面 GitLab 的配置。隨後點選左下角的 儲存 按鈕，儲存前面所做的配置。

配置 GitLab 工程

建立一個新的或選擇一個已有的 GitLab 工程。然後選擇 Settings -> Integrations，在 URL 一欄中輸入前面儲存的 GitLab CI Service URL，在 Secret Token 一欄中輸入前面儲存的 Secret token，然後選擇需要 trigger Jenkins 工程執行構建的事件：

點選綠色的 Add webhook 按鈕，完成 webhook 的建立。

建立好了 webhook 之後，點選 Test 下拉框中的 Push events，如下圖：

可以手動產生事件，觸發 Jenkins 工程。點選 Edit，在 webhook 的編輯頁面，拉到頁面底部，還可以看到，該 webhook 最近的呼叫情況，如下圖：

點開特定呼叫的 View details，還可以看到這次呼叫的詳細情況，如下圖：

由此不難理解，GitLab trigger Jenkins 工程，主要是通過向 Jenkins 伺服器傳送一個 POST 請求實現的。

驗證測試

修改我們的 GitLab 測試工程中的檔案，並 push 到 GitLab 伺服器上：

➜ test_for_gerrit git:(master) echo "Hello, world" >> read2.md

➜ test_for_gerrit git:(master) ✗ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
 (use "git add <file>..." to update what will be committed)
 (use "git checkout -- <file>..." to discard changes in working directory)  modified:  read2.mdno changes added to commit (use "git add" and/or "git commit -a")
➜ test_for_gerrit git:(master) ✗ git add .
➜ test_for_gerrit git:(master) ✗ git commit -m "Add test data."➜ test_for_gerrit git:(master) git pushwarning: push.default is unset; its implicit value has changed inGit 2.0 from 'matching' to 'simple'. To squelch this messageand maintain the traditional behavior, use:

 git config --global push.default matching

To squelch this message and adopt the new behavior now, use:

 git config --global push.default simple

When push.default is set to 'matching', git will push local branches
to the remote branches that already exist with the same name.

Since Git 2.0, Git defaults to the more conservative 'simple'behavior, which only pushes the current branch to the corresponding
remote branch that 'git pull' uses to update the current branch.

See 'git help config' and search for 'push.default' for further information.
(the 'simple' mode was introduced in Git 1.7.11. Use the similar mode'current' instead of 'simple' if you sometimes use older versions of Git)

Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 312 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
To ssh://[email protected]:22222/cloudgame/test_for_gerrit.git  23660c1..e86152a master -> master
➜ test_for_gerrit git:(master)

隨後迅速地就能在 Jenkins 中，測試工程主頁面的左下方，看到由 GitLab push 所 trigger 起來的構建任務：

在由 GitLab push 所 trigger 起來的構建任務的下方，會顯示構建任務是由誰 push 的程式碼所 trigger 起來的。開啟特定構建任務的 控制檯輸出 可以看到構建的詳細過程：

參考文件：

Jenkins CI service Gitlab自動觸發Jenkins構建打包

網易雲新使用者大禮包：https://www.163yun.com/gift

本文來自網易實踐者社群，經作者韓鵬飛授權釋出。