GitLab CI 模板生成器

要解决的具体问题

在 GitLab 项目里手写 .gitlab-ci.yml，很快就会撞上三类问题：

• 构建方式不统一：同一个组织里，有的 job 跑在 Runner 的 Docker executor 上，有的依赖 shell 脚本拼 docker build，换环境就要重写。
• 安全扫描接入靠运气：SAST、DAST 常被当成“以后再补”的步骤；等到合规要求压下来，才发现流水线里根本没有稳定的扫描 stage 和产物出口。
• 多项目流水线靠复制粘贴：多个仓库需要按顺序触发、跨项目传递制品时，配置散落在各个项目里，维护成本高，边界也容易写错。

技能如何工作

这个技能用于生成可放入仓库的 GitLab CI/CD 流水线模板。它会围绕以下能力组织配置：

• 使用 Auto DevOps components 搭建默认流水线骨架，减少从零编写 stages 和 rules 的负担。
• 使用 Kaniko 执行容器镜像构建，避免在 Runner 上依赖特权 Docker daemon，更适合受限环境。
• 集成 SAST/DAST security scanning，把安全检查作为流水线中的独立环节，而不是事后补丁。
• 支持 multi-project pipelines，并通过 trigger jobs 拉起下游项目，或用 bridge jobs 表达当前阶段完成后才执行的跨项目依赖。

一次典型使用流程是：给出项目类型、构建目标、扫描要求以及跨项目触发关系；技能据此生成一份结构化 .gitlab-ci.yml 模板。你可以直接提交模板，也可以先在分支上验证 job 划分、阶段顺序和跨项目依赖是否符合预期。

适用边界与注意点

它适合作为流水线的起点或标准化模板，不能替代你对仓库、Runner 和部署目标的理解。需要注意：

• Auto DevOps 的默认行为可能和现有 CI 配置冲突；迁移前应关闭或覆盖你不希望自动启用的部分。
• Kaniko 构建会拉取基础镜像和依赖，网络策略、镜像缓存与构建缓存需要单独评估。
• SAST/DAST 会产生告警和额外运行时间；扫描范围、误报处理和修复责任应纳入团队约定。
• trigger 与 bridge 会扩大项目间耦合；下游项目的 token、变量、权限和流水线触发条件需要提前确认。

生成后仍建议用 merge request 做小步验证，不要把模板当作一次性接入、永久不用维护的配置。