yml文件结构

YAML 本身是干嘛的？

YAML = Yet Another Markup Language（或 YAML Ain’t Markup Language）

它是一种人类可读的配置语言，特点是：

• 用 缩进 表示层级（像 Python）
• 用 : 和 - 表示键值对和列表
• 几乎没有多余符号（不像 JSON 那么多 {}[]）

✅ 易读
✅ 易写
✅ 非常适合 CI / 容器 / 云原生配置

---

在 GitLab CI 里，YAML 具体“管什么”？

.gitlab-ci.yml 负责描述 整个流水线（Pipeline）：

概念	YAML 里怎么体现
有哪些阶段	stages:
有哪些任务	job 名（如 compile、smoke）
任务属于哪个阶段	stage:
在哪个 Runner 上跑	tags:
跑哪些命令	script:
什么时候跑	rules: / when:
产物怎么保存	artifacts:

---

GitLab 预定义变量（常用）

这些是 GitLab 自动注入的环境变量：

变量	含义
CI_COMMIT_SHA	当前 commit hash
CI_COMMIT_BRANCH	分支名
CI_PROJECT_NAME	项目名
CI_JOB_ID	job ID
CI_PIPELINE_ID	pipeline ID
CI_REGISTRY	GitLab 容器镜像库地址

yml文件结构解析

stages—— 阶段顺序

stages:
  - build
  - test
  - deploy

• 定义顺序，不代表一定执行
• 同一 stage 的 job 并行跑
• 下一 stage 等上一 stage 全部成功后才开始

job—— 任务（最核心的概念）

job_name:
  stage: test
  script:
    - echo "I am a job"

字段	必填	说明
script	✅	要执行的命令（数组或字符串）
stage	❌	默认 test
image	❌	用哪个 Docker 镜像
rules	❌	什么时候跑
variables	❌	环境变量
tags	❌	指定 Runner
artifacts	❌	产物
cache	❌	缓存
dependencies	❌	依赖哪些 job 的 artifacts

rules—— 控制 Job 是否被创建

常见条件变量：

rules:
  - if: $CI_COMMIT_BRANCH == "main"
    when: always
  - when: never

变量	含义
$CI_COMMIT_BRANCH	当前分支
$CI_MERGE_REQUEST_ID	MR ID（有值说明是 MR）
$CI_PIPELINE_SOURCE	pipeline 来源
$CI_COMMIT_TAG	tag 名

关于before_script、after_script

before_script是干嘛的？
在每个 job 的 script执行之前，先跑的一段命令。
可以理解成：job 级别的"前置准备"。
after_script同理，不赘述。
基本用法
以下是job级的用法

job:
  script:
    - echo "running tests"
  before_script:
    - echo "preparing environment"
    - apt-get update

以下是全局级的用法

before_script:
  - echo "global setup"

job1:
  script:
    - echo "job1"

job2:
  script:
    - echo "job2"

job1和 job2都会先跑 global setup。

当同时定义全局级和job级的before_script或after_script时：

before_script:
  - echo "global"

job:
  before_script:
    - echo "job-specific"
  script:
    - echo "work"

此时全局级的before_script会被job级的覆盖

scrpit怎么写？

script就是一个（或一组）Shell 命令列表，GitLab Runner 会按顺序执行它们。
最基本语法（字符串形式）

job:
  script: echo "hello world"

✅ 只有一条命令时，可以直接写字符串。
常用语法（数组形式，推荐）

job:
  script:
    - echo "step 1"
    - echo "step 2"
    - npm install
    - npm test

✅ 多条命令必须用数组（短横线 -）​
✅ 这是 GitLab CI 的标准写法

一个最小 YAML 示例（对比 Makefile）

Makefile 写法

regression:
	vcs -sverilog top.sv

GitLab CI 的 YAML 写法

regression:
  stage: test
  tags: [uvm-sim]
  script:
    - source /tools/eda_setup.sh
    - vcs -sverilog top.sv

📌 区别：

• Makefile：你手动执行
• YAML：GitLab 自动解析并执行

---

YAML 在 UVM平台 回归中的真实角色

你的 .gitlab-ci.yml 实际在做这些事：

# 告诉 GitLab：
# 1️⃣ 先编译
# 2️⃣ 再冒烟
# 3️⃣ 最后全量回归
# 并且每一步都用 EDA 服务器的 shell 跑

相当于把原来你手动敲的命令：

ssh eda-server
cd project
source setup.sh
make regress

变成 GitLab 自动调度、自动记录结果、自动保存 log。

---

YAML 的几个“必须知道”的坑

❌ 1️⃣ 缩进不能用 Tab

job:
    script:     # ❌ Tab

✅ 必须用空格：

job:
  script:
    - echo hello

---

❌ 2️⃣ 少一个 - 就全错

script:
  echo hello   # ❌

✅ 正确：

script:
  - echo hello

---

❌ 3️⃣ 多行命令要小心

script:
  - |
    source /tools/setup.sh
    make compile
    make run

---

YAML ≠ 脚本

YAML	Shell Script
描述“要做什么”	描述“怎么做”
GitLab 解析	Bash 执行
声明式	命令式
不负责计算	负责计算

✅ YAML 里不写复杂逻辑
✅ 复杂逻辑交给 Python / Makefile / Shell