Jenkins 和 Gitlab CI

今天的進度嚴重被干擾 QQ 只好寫點小文，明天才有空可以繼續實測了…..

最近在 trace 公司專案的時候發現，原來公司一開始也有使用 Jenkins（Jenkins是一款開源CI&CD軟體，用於自動化各種任務，包括構建、測試和部署。）。

因此對於兩個的差別產生了點好奇，聽前輩分享，Jenkins 的學習曲線比較高，雖然他有高度可以客製化的彈性，但會需要一些技術專長來設定，也因此在開始及維護上對新手來說並不是那麼友善，另外，雖然兩邊都有大量的第三方套件可以支援，但 GItLab 有內建的安全監控， 更可靠的緩存以及並行處理等的高度效能，最重要的還有整合（提供 Git 儲存、問題跟蹤、程式審查機制和持續集成/持續交付 (CI/CD) 管道等功能），讓 GItLab 在市場上的佔率也漸漸提高。

GitLab Server 與 GitLab CI Runner 的關係

上一篇有提到 GitLab CI Runner （可以執行Runner Service 的平台有很多種，on GNU/Linux, macOS, and Windows (pretty much anywhere you can run Docker).）

Runner 是透過 GitLab API 網路連線到 GitLab Server 上，GitLab Runner 會透過 API 定時向 GitLab 問有沒有新的工作，有的話就接回來做。那假設我們想要指定某個 runner 承接某個特定工作呢？

這時候就可以使用 tags

jobs:
	tags:
		- docker

當然，如果一個 runner 要給很多 project 使用時，也可以設定成 shared runner，例如 gitlab.com 那樣，直接提供不限 User、Project 皆能任意使用的 Runner。或者也可以將 runner 設定成 group runner，如此一來在相同 Group 內的所有 Project 皆能直接取用此 Runner（最近剛好踩到這個雷啊…..）。

以上就是今天的小筆記！明日再戰

參考文章：

• https://ithelp.ithome.com.tw/articles/10238855
• https://chengweichen.com/2021/07/gitlab-api-project-gitlab-runner.html