跳到主內容

【GitLab】CI/CD Settings 說明

 General pipelines

image-1755143476227.png

1. Public pipelines 

  • 功能：允許任何人（即使沒有專案權限）查看 Pipeline 與 Job 詳細資訊，包括 log 和 artifacts。

  • 影響：

    • 開啟：方便外部協作或開源專案 debug。

    • 關閉：僅有有權限的使用者能查看。

2. Auto-cancel redundant pipelines 

  • 功能：在同一分支上，如果新的 Pipeline 啟動，會自動取消舊的 Pending / Running pipeline。

  • 好處：減少資源浪費（例如多次 push 只保留最後一次）。

  • 注意：取消的 pipeline 會標記為 canceled。

3. Skip outdated deployment jobs 

  • 功能：部署任務還沒執行時，如果有新的 pipeline 部署成功，舊的部署 job 就會跳過（不執行）。

  • 應用情境：避免舊版本覆蓋新版本的部署。

4. Use separate caches for protected branches 

  • 功能：對受保護分支（protected branch）使用獨立的 CI cache。

  • 好處：防止非受保護分支的 cache 汙染主分支的 cache（例如 main / master）。

  • 影響：可能增加存儲空間使用。

5. CI/CD configuration file

  • 功能：指定 .gitlab-ci.yml 檔案位置。

  • 預設：.gitlab-ci.yml 在專案根目錄。

  • 用途：

    • 如果 CI 設定檔放在子目錄，可以改成 my/path/ci.yml。

    • 適合 Monorepo 管理多個 CI 配置。

6. Git strategy

  • 選項：

    • git clone：每個 job 都會全新 clone 一份 repo。

    • git fetch（已勾選）：重複使用上一次 job 的工作目錄（workspace），若不存在才 clone。

  • 比較：

    • clone：乾淨，但速度較慢。

    • fetch：快，但可能殘留舊檔案（需注意 job 隔離）。

7. Git shallow clone

  • 數值：20

  • 功能：限制 clone/fetch 的提交數（Depth）。

    • 範例：20 代表只取最後 20 次 commit 歷史。

    • 0 或空白 → 取全部 commit & tags。

  • 好處：減少 clone 時間與流量。

8. Timeout

  • 值：1h（1 小時）

  • 功能：Job 最長允許執行時間。

  • 到時動作：超時會被 GitLab 強制標記為 failed。

  • 可用格式：秒數（3600）、人類可讀（1h、30m）。

我看你的設定，Git strategy 用 fetch + shallow clone 20，這樣拉程式會比較快，但如果你有需要依賴完整 commit 歷史（例如 git describe、全量 tag 檢出），要把 shallow clone 設成 0。

 

image-1755161177902.png

這張圖是 GitLab 專案的 CI/CD 狀態徽章（Badges）設定頁，它提供了一些可以放到 README 或網頁上的「狀態顯示圖示」，用來即時反映專案的 CI/CD 情況。

分三塊說明：

1. Pipeline status（流水線狀態）

  • 顯示當前分支的 CI/CD Pipeline 狀態（成功、失敗、進行中等）。

  • 會即時更新成對應的 SVG 圖示。

  • 三種嵌入格式：

    • Markdown：給 README.md 用

      [![pipeline status](http://10.2.2.3/user/k8s-deploy/badges/master/pipeline.svg)](http://10.2.2.3/user/k8s-deploy/-/commits/master)

    • HTML：可用在網站或 Wiki

      <a href="http://10.2.2.3/user/k8s-deploy/-/commits/master"> <img alt="pipeline status" src="http://10.2.11.139/srou/live-k8s-deploy/badges/master/pipeline.svg" /> </a>

    • AsciiDoc：給 AsciiDoc 格式文件用

2. Coverage report（測試覆蓋率）

  • 需要在 .gitlab-ci.yml 內啟用測試覆蓋率計算（通常透過 coverage: 關鍵字解析測試輸出）。

  • 顯示該分支最近一次 Pipeline 的測試覆蓋率百分比。

  • 格式同上，也提供 Markdown / HTML / AsciiDoc 三種嵌入方式。

3. Latest release（最新版本）

  • 會顯示專案的最新 Release（透過 GitLab Release 功能發佈的版本）。

  • 如果沒有 Release，就會顯示 none（像你現在的狀態）。

  • 格式同上，也提供三種嵌入方式。

4. 使用方式

  • 你可以把 Markdown 格式複製到專案的 README.md，讓別人一眼看到專案的 CI/CD 狀態與測試覆蓋率。

  • 如果有內部 Wiki、Confluence、或是外部網站，也可以用 HTML 格式嵌入。

  • 例如放在 README.md：

    # k8s-deploy
[![pipeline status](http://10.2.2.3/user/k8s-deploy/badges/master/pipeline.svg)](http://10.2.2.3/user/k8s-deploy/-/commits/master)
[![coverage report](http://10.2.2.3/user/k8s-deploy/badges/master/coverage.svg)](http://10.2.2.3/user/k8s-deploy/-/commits/master)

Auto DevOps

image-1755163898687.png

你這張圖是 GitLab Auto DevOps 的設定頁面，它是 GitLab 提供的一套「自動化 CI/CD Pipeline」功能，讓專案在沒有自訂 .gitlab-ci.yml 的情況下，也能自動完成建置、測試、部署等流程。

1. Default to Auto DevOps pipeline

  • 啟用狀態（打勾）
    表示如果專案 沒有 .gitlab-ci.yml，GitLab 就會自動使用 Auto DevOps 預設流程。

  • instance enabled
    表示這個功能已在 GitLab 系統層級啟用，專案可以直接用。

  • 如果你已經在專案內放了 .gitlab-ci.yml，這個設定不會生效（因為會優先用自訂 Pipeline）。

2. 提示訊息

Add a Kubernetes cluster integration with a domain, or create an AUTO_DEVOPS_PLATFORM_TARGET CI variable.

  • Auto DevOps 預設會部署到 Kubernetes，所以 GitLab 建議：

    1. 整合 Kubernetes 叢集（在 GitLab CI/CD > Clusters 中設定）

    2. 或者在 CI/CD 變數中設定 AUTO_DEVOPS_PLATFORM_TARGET（指定部署平台）

3. Deployment strategy（部署策略）

三種選項：

  1. Continuous deployment to production（持續部署到正式環境）

    • 每次 Pipeline 成功就會自動部署到 Production。

  2. Continuous deployment to production using timed incremental rollout（定時漸進式部署）

    • 部署會分批釋出，逐漸更新所有節點（需要 Kubernetes 支援）。

  3. Automatic deployment to staging, manual deployment to production（自動部署到測試環境，手動部署到正式環境）

    • 先自動部署到 Staging 環境，Production 需要手動觸發。

4. 總結影響

  • 如果勾選這個設定，且專案沒有 .gitlab-ci.yml，就會自動跑 GitLab 預設的 Auto DevOps 流程。

  • Auto DevOps 預設：

    • 會進行 build → test → code quality → security scan → review app → deploy 等階段

    • 預期環境是 Kubernetes

    • 如果沒有 K8s，就需要自行設定變數（像 AUTO_DEVOPS_PLATFORM_TARGET）或調整成 Docker / VM 方式

Runners

image-1755165012676.png

 

1. Runners 概念

  • Runner 是 GitLab CI/CD 的執行代理，用來接收並執行 pipeline job。

  • 可以註冊在不同機器上（VM、Docker、K8s 等）。

  • 有兩種主要分類：

    • Specific runners（專案專用）

    • Shared runners（全 GitLab 共用）

2. Specific runners

這個區塊是專屬於當前專案的 Runner。
圖片中有兩個 active 的 Runner：

Runner 名稱 類型 Tag 狀態
#347 (UgMp--WG) Docker Executor app-docker-204 🟢 active
#343 (Mw1g8wwh) Shell/VM Executor app-docker-vm-204 🟢 active

Tag 作用：

  • .gitlab-ci.yml 中 tags: ["app-docker-204"] 會指定 job 只能由對應的 Runner 執行。

  • 如果 job 沒有 tags，而 Runner 又設定了「不允許 untagged job」，則不會被這個 Runner 接手。

3. Runner 註冊方式

左邊「Set up a specific runner for a project」提供：

  • GitLab 伺服器 URL：

    http://10.X.X.X/

  • 專案 Registration Token（圖片中有一段）
    用 gitlab-runner register 時會用到。

4. Shared runners

  • 當前 GitLab 沒有設定任何 Shared Runner（全域共用）。

  • 「Enable shared runners for this project」是打開的，但因為 instance 沒有 shared runner，所以沒有作用。

5. Group runners

  • 用於同一 GitLab group 底下多個專案共享 Runner。

  • 目前這個專案不屬於任何 group，所以無法使用 group runner。

6. 運作重點

  • 你有兩台 runner：

    • app-docker-204 → Docker executor，跑 job 時會用容器。

    • app-docker-vm-204 → Shell executor，直接在 VM 上跑。

  • 兩者可以同時存在，但必須在 .gitlab-ci.yml 指定正確的 tag，否則可能出現「no runner can run the job」的錯誤。

如果你要的話，我可以幫你畫一張
這兩個 Runner + tag 運作流程圖，讓你清楚知道 .gitlab-ci.yml 裡不同 tags 會怎麼派發到哪台 runner。
你要我畫給你嗎？這樣未來切換 runner 會很直觀。

回到頂端