GitLab CI/CD 核心概念与快速上手

GitLab CI/CD 由两部分组成：

.gitlab-ci.yml：放在仓库根目录的声明式配置，定义流水线做什么
Runner：独立进程/容器，负责拉取并执行 Job；GitLab 服务端只负责解析与调度

执行链路：推代码 → GitLab 解析 yml → 创建 Pipeline → 按 Stage 顺序把 Job 分发给匹配的 Runner → Runner 用指定 Executor 执行脚本 → 回传日志与产物。

核心概念

概念	说明
Pipeline	一次完整的自动化流程，由若干 Stage 组成，是顶层执行单元
Stage	阶段（如 build/test/deploy），同 Stage 的 Job 并行，不同 Stage 默认串行
Job	最小执行单元，本质是一组 shell 脚本 + 运行环境声明
Runner	执行 Job 的 agent，分 instance（shared）/ group / project 三级作用域
Executor	Runner 的执行后端：shell / docker / kubernetes 等
DAG	用 `needs` 打破 Stage 边界，按 Job 级依赖提前并行

Pipeline 四种结构：

线性：Stage 串行，最常用
DAG：needs 指定 Job 级依赖，更早开始执行
父子：一个 Job 用 trigger: include: 拉起子流水线
多项目：trigger: project: 触发另一个仓库的流水线

触发方式

来源	`CI_PIPELINE_SOURCE` 值
代码推送	`push`
Merge Request	`merge_request_event`
Tag	`tag`
定时调度	`schedule`
Web 手动	`web`
API	`api`
上游流水线触发	`trigger` / `pipeline`

快速上手：最小可用配置

仓库根目录创建 .gitlab-ci.yml：

stages:
  - test
  - build
 
unit-test:
  stage: test
  image: golang:1.24
  script:
    - go vet ./...
    - go test ./...
 
build-binary:
  stage: build
  image: golang:1.24
  script:
    - go build -o app ./cmd/app
  artifacts:
    paths:
      - app
    expire_in: 1 week

提交后在 Build → Pipelines 查看执行状态。前提：项目有可用 Runner（共享 Runner 或自行注册的，见 cicd-runner）。

UI 导航速查

要看什么	路径
流水线列表	项目 → Build → Pipelines
Job 日志	Pipeline 详情 → 点 Job
DAG 依赖图	Pipeline 详情右上角 DAG
在线编辑/校验配置	Build → Pipeline editor
CI/CD 变量	Settings → CI/CD → Variables
Runner 管理	Settings → CI/CD → Runners
环境与部署记录	Operate → Environments

手册分册导航

cicd-yaml-syntax：.gitlab-ci.yml 语法与关键字参考
cicd-variables：变量体系（预定义/自定义/protected/masked）
cicd-runner：Runner 安装、注册与配置
cicd-recipes：实战示例（Docker 构建、K8s 部署）与排障

zhaoweiguo 的知识库

目录