GitLab 自動觸發 Jenkins 構建

GitLab 自動觸發 Jenkins 構建

在 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://git@g.hz.netease.com:22222/cloudgame/test_for_gerrit.git   23660c1..e86152a  master -> master
➜  test_for_gerrit git:(master)

 

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

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