【GitLab】CI/CD Settings 說明

✅ General pipelines

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。

✅ Pipeline status

這張圖是 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

你這張圖是 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（部署策略）

三種選項：

Continuous deployment to production（持續部署到正式環境）
- 每次 Pipeline 成功就會自動部署到 Production。
Continuous deployment to production using timed incremental rollout（定時漸進式部署）
- 部署會分批釋出，逐漸更新所有節點（需要 Kubernetes 支援）。
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

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」的錯誤。

✅ Artifacts

Uploaded image

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

Artifacts
- Artifact 是 GitLab CI/CD 在 Job 結束後產生的檔案（例如：build 結果、測試報告、壓縮檔）。
- 這些檔案可以被下載、或傳到後續的 Job 使用。
Keep artifacts from most recent successful jobs（已勾選 ✅）
- 啟用後，系統會只保留最後一次成功的 Pipeline 所產生的 artifact。
- 舊的 artifact 會被自動刪掉，節省儲存空間。
- 適合只想保留最新版本的成果（例如：最後打包的 image、最後的前端編譯檔）。
作用機制
1. 你的 pipeline 跑成功後 → Job 產生 artifact → 存下來。
2. 下一次成功的 pipeline 出現 → GitLab 自動刪掉前一次成功的 artifact → 只留最新的。

使用情境

適合 持續整合/持續部署（CI/CD），因為通常只需要最新的 build 產物。
不適合需要保留歷史版本（例如回溯除錯、審計）的專案，此時應該在 .gitlab-ci.yml 裡設定 expire_in 來控制保存期限。

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

✅ Variables（變數）

1. Variables（變數）

存放的資料可以在 .gitlab-ci.yml 的 job script 中透過 $KEY 方式存取，例如 $PassWd、$UserName。
避免將敏感資料直接寫在 .gitlab-ci.yml 裡。

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. 圖中範例

PassWd：
- Protected ✅
- Masked ✅（所以在 job log 裡看不到明碼）
- 適用於所有環境（All）。
UserName：
- Protected ✅
- Masked ❌（會以明碼顯示在 job log，如果有 echo $UserName 會直接看見）。

4. 使用範例

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

stages:
  - test

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

如果 Masked 是 ✅ → job log 會看到 Password: *****
如果 Masked 是 ❌ → job log 會看到明碼 Password: mypassword

在 GitLab 裡，

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

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

1. Protected branch（受保護分支）

主要特點：

只能特定角色（例如 Maintainer、Owner）push 及 merge。
一般用來保護 主要分支（例如 master、main、release）。
通常會搭配 Code Review / Merge Request 流程使用，避免直接修改。
也可以設定 誰可以直接 push、誰只能 merge。

範例情境

master 分支設為 Protected → 只有 Maintainer 能 merge 到 master。
Developer 想要改 master，必須透過 Merge Request 並經過審核。

2. Protected tag（受保護標籤）

主要特點：

限制誰可以建立或刪除特定的 Tag。
通常用來保護 版本發布標籤（例如 v1.0.0）。
避免有人隨便重建同名 Tag 導致部署混亂。

範例情境

v* 標籤設為 Protected → 只有 Maintainer 可以建立 v1.2.0 這類 Tag。
防止 Developer 私自發佈或覆蓋版本。

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

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

這個變數 只會注入 到針對 Protected branch 或 Protected tag 觸發的 Pipeline。
如果在非受保護分支（例如 feature/test）觸發 Pipeline，變數不會被注入，避免敏感資料外洩。

舉例

deploy:
  stage: deploy
  script:
    - echo $PROD_API_KEY

如果 $PROD_API_KEY 是 Protected ✅：
- 在 master（Protected branch）觸發 → 可以用。
- 在 dev（非 Protected branch）觸發 → 不會注入，變成空值。

這是 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 都能用變數

💡 建議用法

部署金鑰 / 密碼 / Token → 設為 Protected ✅，避免在測試分支外洩。
測試環境參數 → 可以不 Protected ❌，讓所有分支都能測試。

✅ Pipeline triggers

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

1. Trigger Token

這是一組唯一的金鑰（圖中 glptt-49dbb6d...）。
持有這個 Token 的人，就能用 API 或 Webhook 觸發該專案的 Pipeline。
權限等同於建立它的帳號，但只能用來觸發 Pipeline，不能直接讀取或修改程式碼。

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

ref：要在哪個 branch 或 tag 執行 Pipeline，例如 master 或 release-v1.0。

(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

適合用在簡單的 HTTP 呼叫（像是 Jenkins、監控系統、外部自動化工具）。

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

這樣在 .gitlab-ci.yml 中可以用 $RUN_NIGHTLY_BUILD 判斷。

4. 使用場景

定時觸發：配合 cron job，每天固定時間呼叫 API。
外部事件觸發：例如其他系統部署完成後自動通知 GitLab 進行後續工作。
跨專案觸發：一個專案完成後，透過 Token 觸發另一個專案的 Pipeline。

💡 建議：

不要把 Trigger Token 放在公開的地方（例如公開 repo）。
如果 Token 洩漏，任何人都可以觸發你的 Pipeline（甚至傳遞惡意變數）。
若外部要用，最好配合 Protected Branch 來限制觸發範圍。

✅ Deploy freezes（部署凍結）

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

圖中設定解讀

Freeze start：10 1 * * *
代表每天 01:10 開始凍結部署（Cron 語法：分時日月星期）。
Freeze end：10 3 * * *
代表每天 03:10 結束凍結部署。
Time zone：[UTC +8] Taipei
表示時間以台北時區計算。

功能運作方式

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

要生效，必須在 .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 規則。

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

使用場景

避免在系統流量高峰期誤佈署造成中斷。
避免在假日、深夜維護窗口外誤觸部署。
防止新人誤觸 Pipeline 造成上線事故。

✅ Token Access

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

Limit CI_JOB_TOKEN access（開關）
- 預設關閉（灰色），代表 任何專案 都能被這個專案的 CI_JOB_TOKEN 存取。
- 開啟後（藍色），就可以指定只有被列入清單的專案能被存取。
Add an existing project to the scope
- 在這裡輸入 GitLab 專案路徑（例如：gitlab-org/gitlab），將其加入允許清單。
- 這樣 CI_JOB_TOKEN 就只能存取清單內的專案 API。
Projects that can be accessed
- 圖中顯示的 Live K8s Deploy 就是允許被目前專案的 CI_JOB_TOKEN 直接存取的另一個專案。

用途

跨專案存取 API
在 CI/CD pipeline 中，可能需要用 curl 或 wget 呼叫其他 GitLab 專案的 API，例如下載 artifact、觸發 pipeline。
限制安全風險
如果沒有啟用限制，惡意程式碼可以利用 CI_JOB_TOKEN 存取同一 GitLab instance 中所有公開或有權限的專案。
最佳實務
- 如果專案需要 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。

【GitLab】gitlab-runner 執行環境種類

【GitLab】升級相關

【GitLab】runner 使用 k8s 流程說明

【GitLab】CI/CD Settings 說明

【GitLab】使用ssh clone 專案

【Git】Github 新增專案檔案

【Git】解決github項目體積過大的問題

【Ｇit】相關連結

【Git】還原相關

【Git】TorotoiseGit 占用資源解決方法

【Git】windows系統 warning: LF will be replaced by CRLF in

【Git】checkout 與 switch 比較

【Git】HEAD 是什麼

【Git】每個 commit 不都是從某個分支出來的嗎？

【Git】head, tag, commit, branch的關係

【Git】git revert <commit> 和 git checkout <commit> 差異

【GitLab】CI/CD Settings 說明

✅ General pipelines

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

✅ Pipeline status

1. Pipeline status（流水線狀態）

2. Coverage report（測試覆蓋率）

3. Latest release（最新版本）

4. 使用方式

✅ Auto DevOps

1. Default to Auto DevOps pipeline

2. 提示訊息

3. Deployment strategy（部署策略）

4. 總結影響

✅ Runners

1. Runners 概念

2. Specific runners

3. Runner 註冊方式

4. Shared runners

5. Group runners

6. 運作重點

✅ Artifacts

使用情境

✅ Variables（變數）

1. Variables（變數）

2. 欄位說明

3. 圖中範例

4. 使用範例

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

1. Protected branch（受保護分支）

主要特點：

2. Protected tag（受保護標籤）

主要特點：

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

✅ Pipeline triggers

1. Trigger Token

2. 觸發方式

(1) 用 cURL

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

(3) 用 Webhook 直接 GET

3. 傳入 Pipeline 變數

4. 使用場景

✅ Deploy freezes（部署凍結）

圖中設定解讀

功能運作方式

使用場景

✅ Token Access

用途

範例：跨專案下載 Artifact

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

(1) 用 `cURL`

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