GitLab CI/CD Pipeline Generator
概述
生成遵循当前最佳实践、安全标准和命名约定的生产就绪GitLab CI/CD管道配置。在创建新的GitLab CI/CD资源、实施CI/CD管道或从头开始构建GitLab管道时，请使用此技能。
强制预生成步骤
**关键：**在生成任何GitLab CI/CD管道之前，您必须完成以下步骤：
第1步：加载参考文件（必需）
您必须使用阅读工具在生成之前加载参考文件。这不是可选的。
始终在生成之前阅读所有四个参考文件：
1. references/best-practices.md - 用于安全、性能和命名模式
2. references/common-patterns.md - 用作基础的标准管道模式
3. references/gitlab-ci-reference.md - 用于语法参考和关键字详情
4. references/security-guidelines.md - 用于安全敏感配置
此外，阅读适当的管道类型模板：
- Docker管道 →
assets/templates/docker-build.yml - Kubernetes部署 →
assets/templates/kubernetes-deploy.yml - 多项目管道 →
assets/templates/multi-project.yml - 基本管道 →
assets/templates/basic-pipeline.yml
第2步：确认理解（需要明确的输出）
阅读参考后，您必须输出一个明确的确认声明。这不是可选的。
所需确认格式：
## 参考分析完成
**识别的管道模式：** [模式名称] 来自 common-patterns.md
- [为什么这个模式合适的简短描述]
**要应用的最佳实践：**
- [列出3-5个与此管道相关的关键最佳实践]
**安全指南：**
- [列出要实施的安全措施]
**模板基础：** [模板文件名]
- [将从此模板定制的内容]
示例确认声明：
## 参考分析完成
**识别的管道模式：** Docker构建+Kubernetes部署来自common-patterns.md
- 用户需要将容器化部署到K8s集群，带有暂存/生产环境
**要应用的最佳实践：**
- 将所有Docker映像固定到特定版本（不是：latest）
- 对pip依赖项使用缓存
- 使用`needs`关键字实现DAG优化
- 对所有作业设置明确的超时（15-20分钟）
- 对部署作业使用resource_group
**安全指南：**
- 对secrets使用掩码CI/CD变量（KUBE_CONTEXT，注册表凭据）
- 包括容器扫描Trivy
- 永远不要在日志中暴露secrets
**模板基础：** docker-build.yml + kubernetes-deploy.yml
- 结合Docker构建模式和K8s kubectl部署
- 添加Python特定的测试作业
如果您跳过此确认步骤，生成的管道可能会错过参考文件中记录的关键模式。
核心能力
1. 生成基本CI/CD管道
创建完整的、生产就绪的.gitlab-ci.yml文件，具有适当的结构、安全最佳实践和高效的CI/CD模式。
何时使用：
- 用户请求：“为…创建GitLab管道”，“构建CI/CD管道…”，“生成GitLab CI配置…”
- 场景：CI/CD管道，自动化测试，构建自动化，部署管道
流程：
- 理解用户的需求（需要自动化什么）
- 确定阶段、作业、依赖关系和工件
- 使用
assets/templates/basic-pipeline.yml作为结构基础 - 参考
references/best-practices.md以实施模式 - 参考
references/common-patterns.md以获得标准管道模式 - 遵循这些原则生成管道：
- 使用语义阶段和作业名称
- 将Docker映像固定到特定版本（不是：latest）
- 使用掩码变量实现适当的机密管理
- 对依赖项使用缓存以提高性能
- 实现适当的工件处理和过期
- 适当时使用
needs关键字进行DAG优化 - 添加适当的错误处理，重试和允许失败
- 使用
rules而不是已弃用的only/except - 对所有作业设置明确的
timeout（通常10-30分钟） - 在注释中添加有意义的作业描述
- 始终验证生成的管道，使用devops-skills:gitlab-ci-validator技能
- 如果验证失败，请修复问题并重新验证
示例结构：
# 基本CI/CD管道
# 构建、测试和部署应用程序
stages:
- build
- test
- deploy
# 全局变量
variables:
NODE_VERSION: "20"
DOCKER_DRIVER: overlay2
# 所有作业的默认设置
default:
image: node:20-alpine
timeout: 20 minutes # 所有作业的默认超时
cache:
key: ${CI_COMMIT_REF_SLUG}
paths:
- node_modules/
before_script:
- echo "Starting job ${CI_JOB_NAME}"
tags:
- docker
interruptible: true
# 构建阶段 - 编译应用程序
build-application:
stage: build
timeout: 15 minutes
script:
- npm ci
- npm run build
artifacts:
paths:
- dist/
expire_in: 1 hour
rules:
- changes:
- src/**/*
- package*.json
when: always
- when: on_success
# 测试阶段
test-unit:
stage: test
needs: [build-application]
script:
- npm run test:unit
coverage: '/Coverage: \d+\.\d+%/'
artifacts:
reports:
junit: junit.xml
coverage_report:
coverage_format: cobertura
path: coverage/cobertura-coverage.xml
test-lint:
stage: test
needs: [] # 可以立即运行
script:
- npm run lint
allow_failure: true
# 部署阶段
deploy-staging:
stage: deploy
needs: [build-application, test-unit]
script:
- npm run deploy:staging
environment:
name: staging
url: https://staging.example.com
rules:
- if: $CI_COMMIT_BRANCH == "develop"
when: manual
deploy-production:
stage: deploy
needs: [build-application, test-unit]
script:
- npm run deploy:production
environment:
name: production
url: https://example.com
rules:
- if: $CI_COMMIT_BRANCH == "main"
when: manual
resource_group: production
2. 生成Docker构建管道
创建用于构建、测试和推送Docker映像到容器注册表的管道。
何时使用：
- 用户请求：“创建Docker构建管道…”，“构建和推送Docker映像…”
- 场景：容器构建，多阶段Docker构建，注册表推送
流程：
- 理解Docker构建需求（基础映像，注册表，标签）
- 使用
assets/templates/docker-build.yml作为基础 - 实施Docker-in-Docker或Kaniko进行构建
- 配置注册表身份验证
- 实施映像标记策略
- 如有需要，添加安全扫描
- 始终验证使用devops-skills:gitlab-ci-validator技能
示例：
stages:
- build
- scan
- push
variables:
DOCKER_DRIVER: overlay2
IMAGE_NAME: $CI_REGISTRY_IMAGE
IMAGE_TAG: $CI_COMMIT_SHORT_SHA
# 构建Docker映像
docker-build:
stage: build
image: docker:24-dind
timeout: 20 minutes
services:
- docker:24-dind
before_script:
- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
script:
- docker build
--cache-from $IMAGE_NAME:latest
--tag $IMAGE_NAME:$IMAGE_TAG
--tag $IMAGE_NAME:latest
.
- docker push $IMAGE_NAME:$IMAGE_TAG
- docker push $IMAGE_NAME:latest
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
retry:
max: 2
when:
- runner_system_failure
# 扫描漏洞
container-scan:
stage: scan
image: aquasec/trivy:0.49.0
timeout: 15 minutes
script:
- trivy image --exit-code 0 --severity HIGH,CRITICAL $IMAGE_NAME:$IMAGE_TAG
needs: [docker-build]
allow_failure: true
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
3. 生成Kubernetes部署管道
创建部署应用程序到Kubernetes集群的管道。
何时使用：
- 用户请求：“部署到Kubernetes…”，“创建K8s部署管道…”
- 场景：Kubernetes部署，Helm部署，kubectl操作
流程：
- 确定Kubernetes部署方法（kubectl，Helm，Kustomize）
- 使用
assets/templates/kubernetes-deploy.yml作为基础 - 配置集群身份验证（服务帐户，kubeconfig）
- 实施适当的环境管理
- 添加回滚能力
- 始终验证使用devops-skills:gitlab-ci-validator技能
示例：
stages:
- build
- deploy
# Kubernetes部署作业
deploy-k8s:
stage: deploy
image: bitnami/kubectl:1.29
timeout: 10 minutes
before_script:
- kubectl config use-context $KUBE_CONTEXT
script:
- kubectl set image deployment/myapp myapp=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA -n $KUBE_NAMESPACE
- kubectl rollout status deployment/myapp -n $KUBE_NAMESPACE --timeout=5m
environment:
name: production
url: https://example.com
kubernetes:
namespace: production
rules:
- if: $CI_COMMIT_BRANCH == "main"
when: manual
resource_group: k8s-production
retry:
max: 2
when:
- runner_system_failure
4. 生成多项目管道
创建触发其他项目或使用父子管道模式的管道。
何时使用：
- 用户请求：“创建多项目管道…”，“触发其他管道…”
- 场景：单体仓库，微服务，编排管道
流程：
- 确定管道编排需求
- 使用
assets/templates/multi-project.yml或父子模板 - 配置适当的工件传递
- 适当时实现并行执行
- 始终验证使用devops-skills:gitlab-ci-validator技能
示例（父子）：
# 父管道
stages:
- trigger
generate-child-pipeline:
stage: trigger
script:
- echo "Generating child pipeline config"
- |
cat > child-pipeline.yml <<EOF
stages:
- build
child-job:
stage: build
script:
- echo "Running child job"
EOF
artifacts:
paths:
- child-pipeline.yml
trigger-child:
stage: trigger
trigger:
include:
- artifact: child-pipeline.yml
job: generate-child-pipeline
strategy: depend
needs: [generate-child-pipeline]
5. 生成基于模板的配置
使用extends、YAML锚点和includes创建可重用模板。
何时使用：
- 用户请求：“创建可重用模板…”，“构建模块化管道配置…”
- 场景：模板库，DRY配置，共享CI/CD逻辑
流程：
- 确定要提取的常见模式
- 创建隐藏作业（以.开头）
- 使用
extends关键字进行继承 - 组织到单独的文件中，使用
include - 始终验证使用devops-skills:gitlab-ci-validator技能
示例：
# 隐藏模板作业（在模板中包含超时）
.node-template:
image: node:20-alpine
timeout: 15 minutes # 默认超时时间为使用此模板的作业
cache:
key: ${CI_COMMIT_REF_SLUG}
paths:
- node_modules/
before_script:
- npm ci
interruptible: true
.deploy-template:
timeout: 10 minutes # 部署作业应有明确的超时
before_script:
- echo "Deploying to ${ENVIRONMENT}"
after_script:
- echo "Deployment complete"
retry:
max: 2
when:
- runner_system_failure
- stuck_or_timeout_failure
interruptible: false # 部署不应被中断
# 实际使用模板的作业
build:
extends: .node-template
stage: build
script:
- npm run build
deploy-staging:
extends: .deploy-template
stage: deploy
variables:
ENVIRONMENT: staging
script:
- ./deploy.sh staging
resource_group: staging
6. 处理GitLab CI/CD文档查找
当生成的管道使用特定的GitLab功能、模板或需要最新文档时：
检测：
- 用户提到特定的GitLab功能（例如，“Auto DevOps”，“SAST”，“依赖项扫描”）
- 用户请求与GitLab模板集成
- 管道需要特定的GitLab运行器功能
流程：
-
确定功能：
- 提取GitLab功能或模板名称
- 确定是否需要版本特定信息
-
使用WebSearch搜索当前文档：
搜索查询模式："GitLab CI/CD [功能]文档2025" 示例： - "GitLab CI/CD SAST模板文档" - "GitLab Auto DevOps配置" - "GitLab依赖项扫描最新" -
分析搜索结果以获取：
- 当前推荐的方法是
- 必需的变量和配置
- 模板包含语法
- 最佳实践和安全建议
- 示例用法
-
如果Context7 MCP可用：
- 尝试使用
mcp__context7__resolve-library-id解析库ID - 使用
mcp__context7__get-library-docs获取文档 - 这提供了结构化的文档
- 尝试使用
-
如果需要特定文档页面：
- 使用WebFetch从docs.gitlab.com检索
- 提取相关配置示例
-
使用发现的信息生成管道：
- 使用正确的模板包含语法
- 配置必需的变量
- 添加安全最佳实践
- 在注释中注明版本和选择
示例使用GitLab模板：
# 包含GitLab的安全模板（使用Jobs/前缀表示当前模板）
include:
- template: Jobs/SAST.gitlab-ci.yml
- template: Jobs/Dependency-Scanning.gitlab-ci.yml
# 通过全局变量自定义SAST行为
# 注意：将变量设置为全局而不是覆盖模板作业
# 以避免由于部分作业定义而导致的验证问题
variables:
SAST_EXCLUDED_PATHS: "spec, test, tests, tmp, node_modules"
DS_EXCLUDED_PATHS: "node_modules, vendor"
SECURE_LOG_LEVEL: "info"
**重要：**当使用
include与GitLab模板时，包含的作业在模板中完全定义。如果您需要自定义它们，更喜欢设置全局变量而不是创建部分作业覆盖（这将在本地验证失败，因为验证器无法解析包含的模板）。GitLab在运行时合并配置，但本地验证器只看到您的.gitlab-ci.yml文件。
验证工作流程
**关键：**每个生成的GitLab CI/CD配置在呈现给用户之前都必须验证。
验证流程
-
生成任何管道配置后，立即调用
devops-skills:gitlab-ci-validator技能：Skill: devops-skills:gitlab-ci-validator -
devops-skills:gitlab-ci-validator技能将：
- 验证YAML语法
- 检查GitLab CI/CD模式合规性
- 验证作业引用和依赖关系
- 检查最佳实践违规
- 执行安全扫描
- 报告任何错误、警告或问题
-
根据严重性分析验证结果并采取行动：
严重性 必需的行动 CRITICAL 必须在呈现之前修复。管道损坏或严重不安全。 HIGH 必须在呈现之前修复。重大的安全或功能问题。 MEDIUM 应在呈现之前修复。应用修复或解释为什么不适用。 LOW 可以修复或承认。通知用户推荐的更改。 SUGGESTIONS 审查并应用如果有益。不需要修复。 -
修复和重新验证循环（对于关键/高问题是必须的）：
当验证存在关键或高问题时： 1. 编辑生成的文件以修复问题 2. 重新运行验证 3. 重复直到没有关键或高问题为止 -
在呈现给用户之前，请确保：
- 零CRITICAL问题
- 零HIGH问题
- MEDIUM问题要么修复了要么解释了为什么可以接受
- LOW问题和建议已确认
-
当向用户呈现验证过的配置时：
- 清楚地说明验证状态
- 列出任何剩余的MEDIUM/LOW问题并解释
- 提供使用说明
- 提及所做的任何权衡
验证通过标准
管道准备好呈现时：
- ✅ 语法验证：通过
- ✅ 安全扫描：没有CRITICAL或HIGH问题
- ✅ 最佳实践：已审核（警告可以接受，需要解释）
管道未准备好时：
- ❌ 存在任何语法错误
- ❌ 存在任何CRITICAL安全问题
- ❌ 存在任何HIGH安全问题
- ❌ 作业引用损坏
何时跳过验证
仅在以下情况下跳过验证：
- 生成部分代码片段（不是完整文件）
- 为文档目的创建示例
- 用户明确要求跳过验证
处理MEDIUM严重性问题（必需输出）
当验证器报告MEDIUM严重性问题时，您必须要么修复它们，要么解释为什么它们可以接受。这个解释是必需的。
MEDIUM问题处理的必需格式：
## 验证问题已解决
### MEDIUM严重性问题
| 问题 | 状态 | 解释 |
|-------|--------|-------------|
| [问题代码] | 已修复/可以接受 | [为什么修复或为什么可以接受] |
示例MEDIUM问题解释：
## 验证问题已解决
### MEDIUM严重性问题
| 问题 | 状态 | 解释 |
|-------|--------|-------------|
| image-variable-no-digest | 可以接受 | 使用`python:${PYTHON_VERSION}-alpine`允许通过CI/CD变量灵活管理版本。PYTHON_VERSION变量在内部受控并固定为"3.12"。SHA摘要固定将需要更新每个图像更新的摘要，增加维护负担而没有显著的安全益处，对于此用例而言。 |
| pip-without-hashes | 可以接受 | 此管道安装了来自PyPI的众所周知的软件包（pytest，flake8）。使用`--require-hashes`将需要维护所有传递依赖的哈希文件。对于内部CI/CD，安全权衡是可以接受的。对于更高安全环境，请考虑使用经过验证的软件包的私有PyPI镜像。 |
| git-strategy-none | 可以接受 | `stop-staging`和`rollback-production`作业使用`GIT_STRATEGY: none`，因为它们只运行不需要源代码的kubectl命令。脚本在YAML中内联（不是来自仓库），因此没有执行不受信任代码的风险。 |
何时修复与接受：
| 场景 | 行动 |
|---|---|
| 生产/高安全环境 | 修复问题 |
| 问题有简单的修复且没有负面影响 | 修复问题 |
| 修复增加复杂性 | 接受并解释 |
| 修复需要外部更改（例如，CI/CD变量） | 接受并解释 |
| 问题对于此上下文是误报 | 接受并解释 |
审查建议（必需输出）
当验证器提供建议时，您必须简要确认它们并解释是否应该应用。
必需格式：
## 验证器建议审查
| 建议 | 建议 | 原因 |
|------------|----------------|--------|
| [建议] | 应用/跳过 | [为什么] |
示例建议审查：
## 验证器建议审查
| 建议 | 建议 | 原因 |
|------------|----------------|--------|
| test jobs上的`missing-retry` | 跳过 | 测试作业是确定性的，不与外部服务交互。重试将掩盖不稳定的测试而不是快速失败。 |
| test-unit上的`parallel-opportunity` | 如果有益则应用 | 如果pytest支持分片，则可以添加`parallel: 3`和`pytest --shard=${CI_NODE_INDEX}/${CI_NODE_TOTAL}`，如果测试套件足够大以受益。 |
| stop-staging上的`dag-optimization` | 跳过 | 此作业是手动运行的，仅在环境清理时运行。DAG优化不会提供有意义的加速。 |
| 生产上的`no-dependency-proxy` | 应用 | 考虑使用`$CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX`以避免Docker Hub速率限制。需要GitLab高级版。 |
| rollback上的`environment-no-url` | 跳过 | 回滚作业不部署新版本，因此URL会误导。 |
| lint作业上的`missing-coverage` | 跳过 | 代码检查不产生覆盖数据。这是一个误报。 |
使用说明模板（必需输出）
在呈现验证过的管道后，您必须提供使用说明。这不是可选的。
必需格式：
## 使用说明
### 必需的CI/CD变量
在**Settings → CI/CD → Variables**中配置这些变量：
| 变量 | 描述 | 掩码 | 受保护 |
|----------|-------------|--------|-----------|
| [VARIABLE_NAME] | [描述] | 是/否 | 是/否 |
### 设置步骤
1. [第一设置步骤]
2. [第二设置步骤]
...
### 管道行为
- **在推送到`develop`时：** [会发生什么]
- **在推送到`main`时：** [会发生什么]
- **在标记`vX.Y.Z`时：** [会发生什么]
### 自定义
[任何自定义说明]
示例使用说明：
## 使用说明
### 必需的CI/CD变量
在**Settings → CI/CD → Variables**中配置这些变量：
| 变量 | 描述 | 掩码 | 受保护 |
|----------|-------------|--------|-----------|
| `KUBE_CONTEXT` | Kubernetes集群上下文名称 | 否 | 是 |
| `KUBE_NAMESPACE_STAGING` | 暂存命名空间（默认：暂存） | 否 | 否 |
| `KUBE_NAMESPACE_PRODUCTION` | 生产命名空间（默认：生产） | 否 | 是 |
**注意：**`CI_REGISTRY_USER`，`CI_REGISTRY_PASSWORD`和`CI_REGISTRY`由GitLab自动提供。
### Kubernetes集成设置
1. **在**Settings → Infrastructure → Kubernetes clusters**中启用Kubernetes集成**
2. **使用代理基础或证书基础方法添加您的集群**
3. **如果不存在，则创建暂存和生产命名空间：**
```bash
kubectl create namespace staging
kubectl create namespace production
- 在运行管道之前确保目标命名空间中存在部署
管道行为
- 在推送到
develop时： 运行测试 → 构建Docker映像 → 自动部署到暂存 - 在推送到
main时： 运行测试 → 构建Docker映像 → 手动部署到生产 - 在标记
vX.Y.Z时： 运行测试 → 构建Docker映像 → 手动部署到生产
自定义
- 更新
APP_NAME变量以匹配您的Kubernetes部署名称 - 修改
deploy-staging和deploy-production作业中的环境URL - 通过取消注释模板中的Helm作业添加Helm部署
## 要强制执行的最佳实践
参考`references/best-practices.md`以获取全面的指导。关键原则：
### 强制性标准
1. **安全第一：**
- 将Docker映像固定到特定版本（不是：latest）
- 对secrets使用掩码变量（$CI_REGISTRY_PASSWORD应该是掩码的）
- 永远不要在日志中暴露secrets
- 验证输入并清理变量
- 对敏感环境使用受保护的变量
2. **性能：**
- 对依赖项安装实施缓存（对npm，pip，maven等总是如此）
- 适当时使用`needs`关键字进行DAG优化（当作业有依赖关系时总是如此）
- 设置工件过期以避免存储膨胀（总是设置`expire_in`）
- 适当时使用`parallel`执行（仅当测试框架支持分片时）
- 最小化不必要的工件传递（当不需要时在`needs`中使用`artifacts: false`）
3. **可靠性：**
- **对所有作业设置明确的`timeout`**（防止挂起的作业，通常10-30分钟）
- 即使使用`default`或`extends`进行超时继承，也要在每个作业中明确设置`timeout`
- 这提高了可读性并避免了验证器关于缺少超时的警告
- 示例：使用`.deploy-template`的作业仍应明确设置`timeout: 15 minutes`
- 为不稳定的操作添加重试逻辑（网络调用，外部API交互）
- 适当使用`allow_failure`用于非关键作业（代码检查，可选扫描）
- 对部署作业使用`resource_group`（防止并发部署）
- 为测试作业添加`interruptible: true`（允许在新提交推送时取消）
4. **命名：**
- 作业名称：描述性，kebab-case（例如，"build-application"，"test-unit"）
- 阶段名称：简短，清晰（例如，"build"，"test"，"deploy"）
- 变量名称：环境变量使用UPPER_SNAKE_CASE
- 环境名称：小写（例如，"production"，"staging"）
5. **配置组织：**
- 使用`extends`进行可重用配置（优先于YAML锚点用于GitLab CI）
- 使用`include`进行模块化管道文件（将大型管道组织到多个文件中）
- 使用`rules`而不是已弃用的only/except（总是）
- 为常见配置定义`default`设置（映像，超时，缓存，标签）
- *仅在必要时*使用YAML锚点用于单个文件中的复杂重复结构
- 注意：`extends`优先，因为它在GitLab UI中提供更好的可视化
6. **错误处理：**
- 设置适当的超时值（总是 - 防止挂起的作业）
- 为不稳定的操作配置重试行为（网络调用，外部API）
- 使用`allow_failure: true`用于非阻塞作业（代码检查，可选扫描）
- 需要时添加清理步骤`after_script`（例如，停止测试容器，清理）
- 需要时实施通知机制（例如，部署失败时的Slack集成）
## 资源
### 参考（按需加载）
- `references/best-practices.md` - 全面的GitLab CI/CD最佳实践
- 安全模式，性能优化
- 管道设计，配置组织
- 常见模式和反模式
- **使用此：**当实施任何GitLab CI/CD资源时
- `references/common-patterns.md` - 常用的管道模式
- 基本CI管道模式
- Docker构建和推送模式
- 部署模式（K8s，云平台）
- 多项目和父子模式
- **使用此：**当选择要使用的模式时
- `references/gitlab-ci-reference.md` - GitLab CI/CD YAML语法参考
- 完整的关键字参考
- 作业配置选项
- 规则和条件执行
- 变量和环境
- **使用此：**用于语法和关键字详情
- `references/security-guidelines.md` - 安全最佳实践
- 机密管理
- 映像安全
- 脚本安全
- 工件安全
- **使用此：**对于安全敏感配置
### 资产（模板定制）
- `assets/templates/basic-pipeline.yml` - 完整的基本管道模板
- `assets/templates/docker-build.yml` - Docker构建管道模板
- `assets/templates/kubernetes-deploy.yml` - Kubernetes部署模板
- `assets/templates/multi-project.yml` - 多项目编排模板
**如何使用模板：**
1. 复制相关模板结构
2. 用实际值替换所有[PLACEHOLDERS]
3. 根据用户需求定制逻辑
4. 移除不必要的部分
5. 验证结果
## 典型工作流程示例
**用户请求：** "为Node.js应用程序创建CI/CD管道，包括测试和Docker部署"
**流程：**
1. ✅ 理解需求：
- Node.js应用程序
- 运行测试（单元，代码检查）
- 构建Docker映像
- 部署到容器注册表
- 在推送和合并请求时触发
2. ✅ 参考资源：
- 检查`references/best-practices.md`以获取管道结构
- 检查`references/common-patterns.md`以获取Node.js + Docker模式
- 使用`assets/templates/docker-build.yml`作为基础
3. ✅ 生成管道：
- 定义阶段（构建，测试，dockerize，部署）
- 创建具有缓存的构建作业
- 创建测试作业（单元，代码检查）与需要优化
- 创建Docker构建作业
- 添加适当的工件管理
- 将Docker映像固定到版本
- 包括适当的机密处理
4. ✅ 验证：
- 调用`devops-skills:gitlab-ci-validator`技能
- 修复任何报告的问题
- 如有需要，重新验证
5. ✅ 呈现给用户：
- 显示验证过的管道
- 解释关键部分
- 提供使用说明
- 提及成功的验证
## 常见管道模式
### 基本三阶段管道
```yaml
stages:
- build
- test
- deploy
build-job:
stage: build
script: make build
test-job:
stage: test
script: make test
deploy-job:
stage: deploy
script: make deploy
when: manual
DAG管道与需求
stages:
- build
- test
- deploy
build-frontend:
stage: build
script: npm run build:frontend
build-backend:
stage: build
script: npm run build:backend
test-frontend:
stage: test
needs: [build-frontend]
script: npm test:frontend
test-backend:
stage: test
needs: [build-backend]
script: npm test:backend
deploy:
stage: deploy
needs: [test-frontend, test-backend]
script: make deploy
条件执行与规则
deploy-staging:
script: 部署暂存
rules:
- if: $CI_COMMIT_BRANCH == "develop"
when: always
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
when: manual
deploy-production:
script: 部署生产
rules:
- if: $CI_COMMIT_BRANCH == "main"
when: manual
- when: never
矩阵并行作业
test:
parallel:
matrix:
- NODE_VERSION: ['18', '20', '22']
OS: ['ubuntu', 'alpine']
image: node:${NODE_VERSION}-${OS}
script:
- npm test
错误消息和故障排除
如果devops-skills:gitlab-ci-validator报告错误：
- **语法错误：**修复YAML格式，缩进或结构
- **作业引用错误：**确保引用的作业存在于需求/依赖关系中
- **阶段错误：**验证所有作业阶段都定义在阶段列表中
- **规则错误：**检查规则语法和变量引用
- **安全警告：**解决硬编码的机密和映像固定
如果找不到GitLab文档：
- 尝试替代搜索查询
- 直接检查docs.gitlab.com
- 查找GitLab存储库中的GitLab CI/CD模板
- 询问用户是否他们有特定版本要求
预交付检查清单
**必需：**在向用户呈现任何生成的管道之前，验证所有项目：
已加载参考文件（全部四个必需）
- [ ] 在生成之前阅读
references/best-practices.md - [ ] 在生成之前阅读
references/common-patterns.md - [ ] 为语法参考阅读
references/gitlab-ci-reference.md - [ ] 为安全模式阅读
references/security-guidelines.md - [ ] 为管道类型阅读
assets/templates/中的适当模板 - [ ] 输出明确的确认声明（第2步格式）
应用了生成标准
- [ ] 所有Docker映像都固定到特定版本（没有
:latest） - [ ] 所有作业都有明确的
timeout（通常10-30分钟） - [ ]
default块包括定义的timeout - [ ] 隐藏模板（
.template-name）包括timeout - [ ] 为依赖项安装配置了缓存
- [ ] 适当时使用
needs关键字进行DAG优化 - [ ] 使用
rules（不是弃用的only/except） - [ ] 为部署作业配置了
resource_group - [ ] 工件设置了
expire_in - [ ] 机密使用掩码CI/CD变量（没有硬编码）
完成验证
- [ ] 调用了
devops-skills:gitlab-ci-validator技能 - [ ] 零CRITICAL问题
- [ ] 零HIGH问题
- [ ] 解决了MEDIUM问题（修复或在输出中解释，使用必需格式）
- [ ] 确认了LOW问题（在输出中列出）
- [ ] 审查了建议（使用必需格式）
- [ ] 在任何修复后重新验证
准备呈现
- [ ] 清楚地说明了验证状态
- [ ] 解释了MEDIUM/LOW问题（带表格格式）
- [ ] 提供了建议审查（带表格格式）
- [ ] 提供了使用说明（变量，设置，行为）
如果任何复选框未勾选，请不要呈现管道。首先完成缺失的步骤。
必需输出部分
您的最终响应必须按顺序包含这些部分：
- 参考分析完成（第2步）
- 生成的管道（
.gitlab-ci.yml内容） - 验证结果摘要（通过/失败状态）
- 解决了验证问题（MEDIUM问题表格）
- 验证器建议审查（建议表格）
- 使用说明（变量，设置，行为）
总结
生成GitLab CI/CD管道时，请始终遵循此顺序：
- 加载参考 - 必须首先阅读所有四个参考文件：
references/best-practices.mdreferences/common-patterns.mdreferences/gitlab-ci-reference.mdreferences/security-guidelines.md- 加上
assets/templates/中的适当模板
- 理解 - 澄清用户需求，阶段和所需的作业
- 生成 - 使用模板并遵循标准（安全，缓存，命名，所有作业的明确超时）
- 搜索 - 对于特定功能，使用WebSearch或Context7获取当前文档
- 验证 - 始终使用devops-skills:gitlab-ci-validator技能
- 修复 - 解决所有关键/高问题，解决中等问题
- 验证清单 - 确认所有预交付检查清单项
- 呈现 - 提供经过验证的，生产就绪的管道和使用说明
生成的GitLab CI/CD管道应该是：
- ✅ 安全，固定映像和适当的机密处理
- ✅ 遵循当前最佳实践和约定
- ✅ 使用适当的配置组织（extends，includes）
- ✅ 针对性能优化（缓存，需求，DAG）
- ✅ 适当记录，带有使用说明
- ✅ 验证零关键/高问题
- ✅ 生产就绪和可维护