【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。

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

我幫你分三塊說明：

1. Pipeline status（流水線狀態）

顯示當前分支的 CI/CD Pipeline 狀態（成功、失敗、進行中等）。
會即時更新成對應的 SVG 圖示。

三種嵌入格式：

Markdown：給 README.md 用

[![pipeline status](http://10.2.11.139/srou/live-k8s-deploy/badges/master/pipeline.svg)](http://10.2.11.139/srou/live-k8s-deploy/-/commits/master)

HTML：可用在網站或 Wiki

<a href="http://10.2.11.139/srou/live-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 中設定）
或者在 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 方式