GitLab CI 脚本之 dependencies 和 needs

dependencies 和 needs 区别和各自的使用场景：

维度	`dependencies`（依赖项）	`needs`（有向无环图 / DAG 依赖）
控制核心	控制 Artifacts（产物）的下载	控制执行顺序与并行度（Pipeline 拓扑结构）
阶段限制（Stages）	严格遵循传统 `stages` 先后顺序（如 Stage 1 必须跑完才能跑 Stage 2）	打破 Stage 限制，子 Job 可跳过前面的 Stage，直接在流水线最开始并行运行
默认行为	如果不写 dependencies（且不使用 needs），GitLab 默认会无条件继承并下载前面所有 Stage 中生成的所有 Artifacts。	当一个 Job 开始使用 needs 关键字时，它会彻底脱离传统的 stages 顺序和默认的全局 Artifacts 继承机制：它只会去下载我们在 needs 列表中明确指定的那些 Job 的产物（默认就是 artifacts: true）。如果我们不想让它下载某个needed Job 的产物，必须显式写出 artifacts: false。

适用 dependencies 的场景：

常规的前后阶段数据传递：希望严格按照定义好的 Stage 顺序执行（例如：先 build 编译，成功后再 test 测试），并且测试 Job 需要用到编译出来的程序集（Artifacts）。

按需过滤产物：当前 Job 在逻辑上属于某个后续阶段，但我们只想让它下载特定前置 Job 的产物，避免下载一堆无关的冗余文件。

适用 needs 的场景：

加速流水线（DAG 拓扑）：比如我的项目有三个完全独立的测试任务（Unit Test、UI Test、Linting），它们都依赖编译产物。使用 needs: $build_job$ 后，一旦 build_job 一完成，这三个测试任务会立即并行启动，不需要等待整个 build 阶段的所有 Job 结束。

跨阶段跳跃执行：某个测试任务不需要等前置的所有慢速 Stage，只要它依赖的特定 Job 一跑完，它就可以马上开始。

多项依赖的 YAML 编写方式：

当一个 Job 需要依赖多个前置 Job 时，dependencies 和 needs 都采用列表（数组）语法格式。

python 复制代码

ui_test_job:
  stage: ui_auto_test
  dependencies:
    - build_job
    - other_prep_job  # 假设还有一个数据准备 Job
  script:
    - ...

注意：多个 dependencies 必须是同一个流水线链条中、排在当前 Stage 之前的 Job。

python 复制代码

deploy_job:
  stage: deploy
  needs:
    - job: build_job
      artifacts: true   # 可选：明确声明是否需要下载该 Job 的产物（默认 true）
    - job: integration_test_job
      artifacts: false  # 不需要它的产物，只要等它成功跑完即可
  script:
    - ...

无论是 dependencies 还是 needs，只要前置依赖的 Job 失败（Failed）了，后置 Job 默认都会被取消（Canceled）或无法运行。

底线逻辑：GitLab CI 默认是"快速失败（Fail-fast）"的。如果 build_job（编译）挂了，后续任何依赖它的测试或部署 Job 都会自动变成 skipped（已跳过）状态，因为连编译产物都没有了，继续跑测试没有任何意义。

例外情况：只有当前置 Job 显式配置了 allow_failure: true（允许失败），后置 Job 才会正常继续执行。

artifacts: true/false 是 needs 专属的高级配置项。而 dependencies 从来不用（也无法）这样配置。

dependencies: \[\] 的意思是：完全不下载前面任何 Job 的产物（即"不下载"）。表示该 Job 不需要任何前置产物，工作目录中只会保留当前 Job 自身产生的内容（或者 Git 仓库拉取的文件），从而跳过下载产物的网络开销。

如果不写 dependencies：GitLab 默认会继承并下载前面所有 Stage 中生成的、带有 artifacts 的产物。

allow_failure 既不属于 dependencies，也不属于 needs，它是 GitLab CI 中所有 Job 都可以配置的"独立全局属性"。它用来控制：当某一个 Job 运行失败（Exit Code 非 0）时，整个 Pipeline 是否继续往下走。它是写在 Job 的根级配置里的（和 stage、script、tags 同级），而不是写在 dependencies 或 needs 内部：

python 复制代码

test_job:
  stage: ui_auto_test
  allow_failure: true   # 即使这个 Job 运行报错失败了，GitLab 也会把状态标记为"允许失败"，并让后续依赖它的 Job 继续正常运行！
  script:
    - dotnet test ...