GitLab CI 流水线迁移工具

解决什么问题

当你需要把团队在 GitLab 上维护的 .gitlab-ci.yml 流水线迁到 GitHub Actions，直接把 YAML 改个名往往行不通：GitLab 的 stages、services、artifacts、only/except、rules 等概念和 GitHub Actions 的 job、step、needs、if、actions/upload-artifact 并不一一对应。手动逐条映射不仅耗时，还容易在阶段依赖、服务容器、产物传递这些细节上出错，导致迁移后的流水线跑起来结果不一致。

技能如何工作

核心能力是把 .gitlab-ci.yml 当作可解析的结构来处理，而不是纯文本替换。

• 使用 gitlab-ci-local 作为解析器，先对源流水线做语义解析，得到阶段、作业、服务、依赖等结构化信息。
• 在 YAML AST 层面做转换，把 GitLab 的声明式配置映射成 GitHub Actions 的等价写法。
• 关键映射包括：GitLab stages → Actions 的 job 依赖（needs）；services → 基于容器的 job 步骤或 services: 配置；artifacts → actions/upload-artifact 与 actions/download-artifact；rules/only → job 级别的 if 条件。

迁移时建议保留原流水线的语义，再在 Actions 侧补齐权限、缓存和运行器约束，避免只改语法却丢了行为。

适用边界与注意点

• 该技能处理的是配置层面的等价转换，不负责改写你的测试脚本、Dockerfile 或业务代码。
• 对于高度依赖 GitLab 特有功能（如 trigger、include 远程配置、复杂 rules 组合、跨项目流水线）的场景，转换后可能需要人工补全或拆分。
• 解析基于 gitlab-ci-local 支持的语法子集，若源文件使用了实验性关键字或旧版写法，可能无法完整识别。
• 迁移后应逐阶段验证 job 的输入输出、产物缓存和失败重试行为，确保与原流水线一致。