本文為系列文章《跟著 GitLab Auto DevOps 學習 CI/CD Pipeline》的第四篇，藉由逐一檢視並解析 GitLab Auto DevOps 背後的 Templates，讓我們一起跟著 GitLab Auto DevOps 學習 GitLab CI/CD Pipeline。
在上一篇文章，我們學習到 workflow: 可以幫助我們控制在哪些條件之下才需要產生 CI/CD Pipeline。這次我們則是要進入第一個 Template - Jobs/Build.gitlab-ci.yml，看看 Auto DevOps 是如何實現同一個 CI Build 卻能適用於不同的程式語言。
此系列文清單：
跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（一） 跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（二） 跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（三） 跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（四） Jobs/Build.gitlab-ci.yml 首先讓我們直搗黃龍，直接查看 Jobs/Build.gitlab-ci.yml 的內容。
# 下面的版本來自 2022/02/04 的 https://gitlab....
在先前的文章，已分享過使用 JMeter 和 drill 進行小規模 Load Testing，今天延續同樣的主題，這次要使用另一個新興熱門的 Load Testing 工具 K6，試一試「如何透過 GitLab CI + K6 進行小規模 Load Testing」。
操作步驟 首先，K6 在 2021 年已經被 Grafana Labs 買下來了，但目前（2022/02/03）看來，K6 官網依然還維持原貌，沒有太大的變化，只是多掛上了 Grafana Labs 的 Logo。K6 有提供 Open Source 與 K6 Cloud 兩種方案，而本文將採用的是 Open Source 方案。
準備 GitLab Runner 老樣子，第一步我們要先預備合適的 GitLab CI 環境，應該不用再多做解釋，請先準備好能夠操控 Container 的 GitLab Runner，如果你不知該如何準備 Runner，又想要快速試一下本文的內容，那最簡單的做法是註冊一個 gitlab.com 帳號，然後建立新 Project 並使用官方提供的 Shared Runners。
準備 Docker image - K6 第二步，預備一個能夠運行 K6 的 Docker image。
這次很幸運，已經有現成的 Image 可以使用 loadimpact/k6...
本文為系列文章《跟著 GitLab Auto DevOps 學習 CI/CD Pipeline》的第三篇，藉由逐一檢視並解析 GitLab Auto DevOps 背後的 Templates，讓我們一起跟著 GitLab Auto DevOps 學習 GitLab CI/CD Pipeline。
在上一篇文章，我們學習了善用 include: 並透過合適的層級規劃，讓我們可以建立出屬於自己的 CI/CD Pipeline Templates。接著在本篇文章，我們要來認識在規劃 GitLab CI Pipeline 時，一個重要的進階功能 workflow:。
此系列文清單：
跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（一） 跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（二） 跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（三） 跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（四） workflow 在本系列文的第一篇我們介紹 Auto-DevOps.gitlab-ci.yml 時，有稍微提到 workflow:，但當時只有快速帶過，說明關於它的一個基本認識，在文章中我是這樣解釋的：
workflow: 類似程式語言中的 if / else，在 GitLab CI 我們可以利用 workflow: 設置不同的條件，藉此控制 GitLab CI 判斷哪些情境之下，才需要產生 CI/CD Pipeline。...
本文為系列文章《跟著 GitLab Auto DevOps 學習 CI/CD Pipeline》的第二篇，藉由逐一檢視並解析 GitLab Auto DevOps 背後的 Templates，讓我們一起跟著 GitLab Auto DevOps 學習 GitLab CI/CD Pipeline。
在上一篇文章，我們了解 Auto DevOps 可說是 GitLab CI 的火力展示，它以 Auto-DevOps.gitlab-ci.yml 為起點，利用 include: 引用了多個 Template，構成了可以自動產生 Pipeline 的 Auto DevOps 功能。本文我們將延續上一篇文章，從 Auto-DevOps.gitlab-ci.yml 繼續認識官方是怎麼規劃與管理 pipeline 與 templates。
此系列文清單：
跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（一） 跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（二） 跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（三） 跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（四） 結構 善用 include: 在上一篇文章，雖然我們只是快速的解釋 Auto-DevOps....
自從 GitLab 推出 Auto DevOps 功能之後，我在許多演講與社群的場合都曾分享過，其實 Auto DevOps 並不是真的那麼「Auto」，它的背後是仰賴 GitLab 官方事先預備好的眾多 GitLab CI Templates，這些 Templates 能夠根據 Project 內容，自動產生多種情境的 CI/CD Pipeline。因此如果你想要自學 GitLab CI 的各種進階用法與技巧，或想要參考別人如何規劃 CI/CD Pipeline，那麼這些建構出 Auto DevOps 的諸多 CI Templates 即是我們絕佳的學習與參考對象。
既然 GitLab 官方準備了這麼好的學習材料，當然要好好運用它，因此從本文開始，接下來我將以系列文的方式，逐一檢視並解析 GitLab Auto DevOps 背後的 Templates，讓我們一起跟著 GitLab Auto DevOps 學習 GitLab CI/CD Pipeline。
此系列文清單：
跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（一） 跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（二） 跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（三） 跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（四） Auto DevOps CI Templates 首先讓我們快速查看 GitLab 官方準備的 Auto DevOps CI Templates，如下網址，我們可以在官方公開的 GitLab Project 中找到它們。...
在 2021 年四月的文章中，我分享了透過 GitLab CI + JMeter 進行小規模 Load Testing；而在 2021 年七月的文章中，我則是試用了 Drill 這個新興的 Load Testing 工具。
承襲這兩次的經驗，在本文我們就以 GitLab CI + Drill，試一試「如何透過 GitLab CI + Drill 進行小規模 Load Testing」。
（本文同步發表於 Medium。）
操作步驟 首先我們要準備合適的 GitLab CI 環境，老樣子會需要一個可以操控 Container 的 GitLab Runner。如果你只是打算先試玩看看，那最簡單的方式就是使用 gitlab.com 以及官方提供的 Shared runners。
【小提醒】再次提醒大家 gitlab.com 的 Free plan 現在只有 400 CI/CD minutes per month。而且由於一直都有人在濫用這些免費資源，因此官方也有在評估該如何規範濫用的狀況。假如你真的想要由 GitLab CI 觸發 Load Testing，最好還是使用自己架設的 GitLab Runner 喔！
準備 Docker image - drill 接著準備合適的 Docker image。這邊一樣偷懶，就不追求容器 size 最小化，用最直白的方式建立一個可以在 GitLab CI 中使用的 Docker image - drill。...
本文只有一個重點，就是介紹可以使用 GitLab API 為 Project 設定 GitLab Runner，如果是使用工具前都會查閱說明書的資深 GitLab 使用者，可以直接轉身離開喔（喂～哪有文章一開頭就把人趕走的～）
（本文撰寫時，使用的 GitLab 環境為 14.0。） （本文同步發表於 Medium。）
前情提要 之前在 GitLab Taipei User Group 中有一位苦主表示遇到了一個狀況，他必須要將指定的 GitLab Runner 分配給超過百個 Project 使用，想詢問有沒有比較簡單的方法？
一般來說如果有 Runner 需要同時供應給多個 Project 使用，通常會建議將 Runner 建立為 Group Runner。如此一來在相同 Group 內的所有 Project 皆能直接取用此 Runner，唯一的限制就是 Project 必須隸屬在相同的 Group。因此對於苦主來說，這個解法他會需要將超過百個 Project 全部搬家至 Group 內，因此不太適用。
另一個方案是，假如你是自架 GitLab Server，則可以透過 Admin 管理者，架設 Shared Runner，便能夠如同 gitlab.com 那樣，直接提供不限 User、Project 皆能任意使用的 Runner。當然要說缺點就是 Shared runner 預設是全開放給所有人皆能使用的 Runner，因此如果你又想要做出額外的權限控管，同樣又要另外想辦法。不幸的是印象中苦主似乎是使用 gitlab.com，GitLab 官方當然沒開放權限讓使用者自行在 gitlab.com 上架設 Shared runner。...