【GitLab】CI/CD Settings 說明

✅  General pipelines

image-1755143476227.png

1. Public pipelines 

2. Auto-cancel redundant pipelines 

3. Skip outdated deployment jobs 

4. Use separate caches for protected branches 

5. CI/CD configuration file

6. Git strategy

7. Git shallow clone

8. Timeout

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

✅ Pipeline status

image-1755161177902.png

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

分三塊說明：

1. Pipeline status（流水線狀態）

2. Coverage report（測試覆蓋率）

3. Latest release（最新版本）

4. 使用方式

✅ Auto DevOps

image-1755163898687.png

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

1. Default to Auto DevOps pipeline

2. 提示訊息

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

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. 總結影響

✅ Runners

image-1755165012676.png

 

1. Runners 概念

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 作用：

3. Runner 註冊方式

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

4. Shared runners

5. Group runners

6. 運作重點

✅ Artifacts

Uploaded image

這張圖是 GitLab 專案的 Artifact 保留設定。

使用情境

 

這張圖是 GitLab CI/CD 專案層級的 Variables 設定頁面，主要是用來存放敏感資訊（例如密碼、金鑰、帳號等），在 Pipeline 中可以直接引用。

✅ Variables（變數）

1. Variables（變數）

2. 欄位說明

欄位 說明
Type 一般都是 Variable，也可能是 File（將值存成檔案再提供給 Job）。
Key 變數名稱（例如 PassWd、UserName），在 CI/CD job 中用 $PassWd 存取。
Value 變數值（已隱藏），只有有權限的使用者才能看到。
Protected ✅ 表示這個變數只會在 Protected branch 或 Protected tag 的 pipeline 中被注入。
Masked ✅ 代表在 Job log 中會以 ***** 隱藏，防止外洩（必須符合 GitLab Mask 規則）。
Environments 變數適用的環境，例如 All、production、staging 等。

3. 圖中範例

4. 使用範例

假設你在 .gitlab-ci.yml 中要用這兩個變數：

stages:
  - test

show-vars:
  stage: test
  script:
    - echo "User: $UserName"
    - echo "Password: $PassWd"

在 GitLab 裡，

Protected branch（受保護分支） 和 Protected tag（受保護標籤）
是用來防止重要分支或標籤被隨意修改、刪除、或由沒有權限的人 push 的安全機制。

Protected branch（受保護分支） 和 Protected tag （受保護標籤）

1. Protected branch（受保護分支）

主要特點：

範例情境

2. Protected tag（受保護標籤）

主要特點：

範例情境

3. 為什麼與 CI/CD Variables 有關

當你在 GitLab CI/CD 中將變數設定為 Protected = ✅ 時：

舉例

deploy:
  stage: deploy
  script:
    - echo $PROD_API_KEY

這是 Protected Branch / Tag 與 CI/CD 變數注入邏輯對照表：

Pipeline 觸發來源 變數 Protected 設定 變數是否注入 說明
Protected branch（例如 master） ✅ Protected ✅ 注入 變數只對受保護分支生效，符合條件可使用
非 Protected branch（例如 feature/test） ✅ Protected ❌ 不注入 變數不會被注入，避免敏感資料外洩
Protected tag（例如 v1.0.0） ✅ Protected ✅ 注入 變數會注入到受保護標籤的 Pipeline
非 Protected tag（例如 test-1） ✅ Protected ❌ 不注入 變數不會被注入
任意 branch/tag ❌ 未 Protected ✅ 注入 不受限制，所有 Pipeline 都能用變數

💡 建議用法

✅ Pipeline triggers

image-1755166426157.png

你這張圖是 GitLab Pipeline Trigger 設定頁面，它的用途是建立一組 Trigger Token，讓外部系統或腳本可以直接觸發專案的 CI/CD Pipeline，而不用透過 Git push 或 Merge Request。

1. Trigger Token

2. 觸發方式

(1) 用 cURL

curl -X POST --fail \
  -F token=YOUR_TOKEN \
  -F ref=分支或tag名稱 \
  http://10.10.10.10/api/v4/projects/2406/trigger/pipeline

(2) 在 .gitlab-ci.yml 裡呼叫

script:
  - "curl -X POST --fail -F token=YOUR_TOKEN -F ref=master http://10.10.10.10/api/v4/projects/2406/trigger/pipeline"

(3) 用 Webhook 直接 GET

http://10.10.10.10/api/v4/projects/2406/ref/master/trigger/pipeline?token=YOUR_TOKEN

3. 傳入 Pipeline 變數

可以讓外部觸發時同時傳遞變數：

curl -X POST --fail \
  -F token=YOUR_TOKEN \
  -F ref=master \
  -F "variables[RUN_NIGHTLY_BUILD]=true" \
  http://10.10.10.10/api/v4/projects/2406/trigger/pipeline

4. 使用場景

💡 建議：

✅ Deploy freezes（部署凍結）

image-1755166820184.png

你這張圖是 GitLab 的 Deploy freezes（部署凍結）設定頁面，用來在特定時間區間禁止部署，避免在敏感時段（例如假日、系統維護時間、尖峰時段）誤發佈程式。

圖中設定解讀

功能運作方式

  1. 這裡的時間範圍只是定義凍結時段。

  2. 要生效，必須在 .gitlab-ci.yml 的部署 job 中加上：

    deploy_job:
  stage: deploy
  script:
    - echo "Deploying..."
  rules:
    - if: $CI_DEPLOY_FREEZE == "true"
      when: never
    - when: on_success

    或使用 GitLab 內建的 deploy_freeze 規則。

  3. 凍結期間，對應的部署 job 會直接跳過，不會觸發。

使用場景

✅ Token Access

image-1755167118948.png

這是 GitLab 專案設定裡的 Token Access（CI_JOB_TOKEN 存取控制） 功能，主要用來限制 CI/CD 任務中 CI_JOB_TOKEN 變數可以存取的其他專案，避免被濫用。

用途

  1. 跨專案存取 API
    在 CI/CD pipeline 中，可能需要用 curl 或 wget 呼叫其他 GitLab 專案的 API，例如下載 artifact、觸發 pipeline。

  2. 限制安全風險
    如果沒有啟用限制，惡意程式碼可以利用 CI_JOB_TOKEN 存取同一 GitLab instance 中所有公開或有權限的專案。

  3. 最佳實務

    • 如果專案需要 CI_JOB_TOKEN 存取別的專案 → 開啟並只加允許的專案。

    • 如果專案不需要跨專案存取 → 建議直接開啟限制並不加任何專案。

範例：跨專案下載 Artifact

假設專案 A 的 pipeline 要下載專案 B 的最新 build：

script:
  - curl --header "JOB-TOKEN: $CI_JOB_TOKEN" \
         "https://gitlab.example.com/api/v4/projects/123/jobs/artifacts/main/download?job=build" \
         -o artifact.zip

如果你啟用了限制，就必須在專案 B 裡把專案 A 加進「Projects that can be accessed」清單，否則會 403 Forbidden。

 

 

修訂版本 #10
由 treeman 建立於 14 K 2025 11:47:26
由 treeman 更新於 14 K 2025 18:26:53