GitLab 流水线编排器

它解决什么问题

手工维护 .gitlab-ci.yml 时，常见的两类成本会随项目规模快速放大：一是流水线结构本身写错——stage 依赖没对齐、job 落在不存在的 stage 里、缓存没生效导致每次都从头构建；二是流水线之间割裂——上游构建完的产物要靠人工去下游仓库重新触发，或者干脆复制一段近似的 YAML 改改。

GitLab 流水线编排器针对的正是这两类问题：它把流水线的创建与串联交给 GitLab 的 Pipelines API 和 .gitlab-ci.yml DSL 来表达，而不是靠人肉复制粘贴。

技能如何工作

核心能力

• 流水线生成：基于 GitLab Pipelines API 与 .gitlab-ci.yml DSL 自动产出 CI/CD 流水线配置，把阶段划分写进版本控制。
• 多阶段构建管理：以 stage 为单位组织 job，让 build、test、deploy 这类阶段之间的依赖关系显式化。
• 构建产物缓存：通过 GitLab Artifacts API 管理 job 产物，使后续 job 或后续运行可以复用之前的结果，减少重复编译。
• 下游流水线触发：借助 bridge jobs 把上游流水线的完成事件接到下游流水线，形成跨项目或跨流水线的接力。

典型流程

1. 描述目标流水线的阶段划分与 job 归属。
2. 生成符合 DSL 的 .gitlab-ci.yml，并确认 stage 与依赖顺序自洽。
3. 为需要复用的构建结果配置 artifact 缓存。
4. 在需要接力的节点上定义 bridge job，指向下游流水线。

适用边界与注意点

• 它的输出边界就是 Pipelines API 与 DSL 的能力边界：API 不支持的调度策略或原生 GitLab 未提供的运行时能力，技能不会凭空补出来。
• bridge job 的上下游必须都真实存在，配置里的流水线引用写错时，故障会在运行期而不是写入期暴露，接入前需要先确认引用关系。
• artifact 缓存的体积与保留策略直接影响流水线耗时和仓库压力，缓存范围要按项目实际的构建产物来定，不宜无条件放大。
• 流水线结构一旦生成，后续演进仍需要仓库维护者自己评审 diff，技能负责生成与串联，不替代对流水线策略的工程判断。