GitLab CI/CD 流水线编排器

它在解决什么问题

当团队同时维护多个仓库时，GitLab 默认只展示单个项目的流水线视图。跨仓库的构建顺序、产物传递、Runner 资源争抢，往往要靠人工约定和临时脚本维持。这些约定久而久之散落在 wiki、issue 和聊天记录里，没人能说清完整的执行链路。

这个技能把流水线当作代码来编排：用一套声明式配置描述多项目流水线、任务依赖关系和 Runner 调度，而不是靠记忆和口头约定。

核心能力与工作方式

技能的工作分三层：

• 声明式流水线：通过 .gitlab-ci.yml 描述 job、stage、变量与依赖，把「什么时候构建、由谁执行」写成可 review、可版本化的代码。
• API 驱动：通过 GitLab REST API v4 触发流水线、查询运行状态、读取日志，脚本无需打开 Web 界面即可完成完整闭环。
• 多项目与 DAG 调度：支持 multi-project pipelines 与 DAG（有向无环图）调度，跨仓库任务按依赖关系并行执行，而不是全链路串行排队。
• Runner 编排：管理 GitLab Runner 节点的注册、标签与调度策略，让构建任务落到合适的机器上。

典型流程：编写或修改 .gitlab-ci.yml → 通过 API 触发流水线 → 观察 DAG 调度结果 → 按 Runner 标签分配任务 → 排查失败日志并迭代。

适用边界与注意点

• 该技能编排的是 GitLab 自身的 CI/CD 能力，不替代 GitLab 服务本身，需要可用的 GitLab 实例和具备权限的 API token。
• 跨项目产物传递依赖 GitLab 的 artifact 机制，需确认项目间可见性设置正确，否则任务可能静默失败。
• DAG 依赖关系只解决调度顺序，不保证构建结果正确，产物质量仍需测试覆盖。
• Runner 规模较大时，标签冲突和资源争抢会成为新的复杂度来源，需要先明确各机器的职责边界。