name: dot-ai-generate-cicd description: 通过交互式对话分析仓库结构和用户偏好，生成智能CI/CD工作流 user-invocable: true
生成CI/CD工作流
通过交互式对话为当前项目生成适当的CI/CD工作流。这个提示分析您的整个仓库，呈现发现，询问工作流偏好，并根据您确认的选择生成工作流。
指令
您正在帮助开发人员为他们的项目设置CI/CD工作流。与基于模板的生成器不同，您将：
- 分析整个仓库 - 源代码、自动化、配置、文档、现有CI
- 呈现发现和提供给用户决策的工作流选项
- 生成基于确认用户选择的工作流
这种交互式模型至关重要，因为CI/CD工作流涉及策略决策（PR与直接推送、发布触发器、部署策略），这些无法仅从代码中推断 - 它们反映团队偏好和组织策略。
关键规则
验证一切：在添加任何步骤、秘密或配置之前，通过检查实际代码库进行验证。从不假设。不确定时询问。
始终呈现工作流选择：CI/CD涉及需要用户输入的策略决策。即使您检测到测试和Dockerfile，您也无法知道测试应在PR还是主分支上运行、什么触发发布、使用哪个注册表或如何部署。这些是需要用户输入的工作流选择。
最佳实践
生成工作流时应用这些实践。
使用项目自动化，而非内联命令
CI工作流应调用项目自动化，而非包含内联命令逻辑。
# ❌ 差 - 逻辑在CI中，无法以相同方式本地运行
- run: |
jest --coverage --ci
eslint src/ --format=stylish
# ✅ 好 - CI调用项目自动化
- run: npm test
- run: npm run lint
原因：本地/CI对等性、CI平台可移植性、更易调试、单一真实来源。
当项目自动化不存在时，询问用户：
我没有找到[操作]的自动化。您希望我：
1. 将其添加到项目中（推荐用于本地/CI对等性）
2. 在工作流中使用内联命令
基础设施使用操作，逻辑使用项目命令
| 类别 | 示例 | 方法 |
|---|---|---|
| CI基础设施 | checkout、设置运行时、缓存、注册表登录 | ✅ 使用操作 |
| 项目逻辑 | 构建、测试、lint、docker构建、部署 | ✅ 使用项目自动化 |
秘密处理
秘密仅可从配置它们的组织/所有者访问。复刻PR无法访问基础仓库秘密。
使用条件在秘密不可用时跳过步骤：
- name: 运行集成测试
if: secrets.API_KEY != ''
run: npm run test:integration
env:
API_KEY: ${{ secrets.API_KEY }}
当生成的工作流需要秘密时，清晰地记录它们：
## 所需秘密
| 秘密名称 | 描述 | 如何创建 |
|-------------|-------------|---------------|
| `REGISTRY_USERNAME` | 容器注册表用户名 | 您的注册表账户用户名 |
| `REGISTRY_TOKEN` | 容器注册表访问令牌 | 注册表设置 > 访问令牌 |
**通过CLI创建秘密：**
gh secret set REGISTRY_USERNAME
gh secret set REGISTRY_TOKEN
显示gh secret set命令作为指导，但不要执行它们。
安全
| 实践 | 描述 |
|---|---|
| 最小权限 | 使用permissions:块，仅授予所需权限 |
| OIDC优于长期令牌 | 对于云提供商，优先OIDC联邦 |
| 固定操作版本 | 使用SHA或版本标签，从不使用@latest |
| 禁用凭证持久化 | 在actions/checkout上使用persist-credentials: false |
| 防止脚本注入 | 永远不要将不受信任的输入（分支名称、PR标题）直接插入run:命令 |
避免pull_request_target |
此触发器可访问秘密但可检出复刻代码 - 危险组合 |
| 环境保护 | 使用GitHub环境与所需审查者用于生产部署 |
测试
| 实践 | 描述 |
|---|---|
| 快速失败 | 在慢检查（测试）之前运行快速检查（lint） |
| 构建前测试 | 如果测试失败，不浪费时间构建 |
| 并行作业 | 并发运行独立检查 |
| 测试矩阵 | 如果相关，考虑多个版本/平台 |
缓存
基于检测到的包管理器和锁文件实现适当缓存。
流程
重要：顺序执行此流程。每个步骤可能改变对话方向。不要提前批处理所有问题 - 逐个阶段询问问题，并在继续前等待用户响应。
工作流遵循三个阶段：
┌─────────────────────────────────────────────────────────────────┐
│ 阶段1: 分析 │
│ 发现可以构建/测试/部署的内容 │
└─────────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────┐
│ 阶段2: 呈现与询问 │
│ 显示发现 + 呈现工作流选择供用户决策 │
└─────────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────┐
│ 阶段3: 生成 │
│ 基于确认用户选择创建工作流 │
└─────────────────────────────────────────────────────────────────┘
步骤0: 确定CI平台（阻塞门）
关键：这是一个阻塞门。首先并单独询问CI平台。在用户确认他们想要GitHub Actions之前，不要询问任何其他问题或执行任何分析。
询问用户使用哪个CI/CD平台。仅呈现这些选项：
- GitHub Actions
- 其他
如果GitHub Actions → 继续到步骤1（分析）
如果其他 → 停止。询问他们使用哪个平台，然后响应：
[平台]尚未支持。您希望我在https://github.com/dot-ai-app/dot-ai/issues打开一个功能请求问题，以便我们优先添加它吗？
1. 是，打开功能请求
2. 否，我将使用不同的方法
然后处理用户响应（创建问题或结束对话）。不要为不支持的平台继续仓库分析。
步骤1: 全面仓库分析
分析一切。整个仓库是上下文。
1.1 语言和框架检测
- 从源文件和依赖清单中识别主要语言
- 从依赖中检测框架
- 注意版本要求
1.2 发现和理解现有自动化
查找现有自动化并阅读脚本以理解它们如何工作 - 它们接受什么参数、内部处理什么、如何调用。不要仅记录脚本存在；理解它。
- 如果存在任务的自动化 → 在生成的工作流中使用它
- 仅当未找到现有自动化时生成原始命令
- 当存在多个自动化选项时 → 询问用户
为什么这重要：现有自动化通常处理设置、夹具、环境变量和清理，这些原始命令会遗漏。维护者选择他们的构建系统是有原因的。
1.3 现有CI分析
检查现有CI配置。如果找到：
- 分析已配置内容及原因
- 在步骤2中，询问用户是更新现有工作流还是创建新工作流
1.4 容器和注册表检测
- 检查Dockerfile和容器配置
- 搜索现有CI、自动化或文档中的注册表引用
- 如果没有Dockerfile但项目可能受益于容器化，建议使用
/generate-dockerfile提示
1.5 分支和发布策略
- 检查现有CI触发器中的模式
- 查看git标签以获取版本控制模式
- 检查文档以获取工作流提示
1.6 环境和秘密
- 查找环境变量文档或示例
- 搜索代码中所需环境变量
- 识别工作流将需要什么秘密
1.7 应用定义检测
识别应用程序如何打包部署：
- Helm图表
- Kustomize配置
- 纯Kubernetes清单
- 仅容器（无K8s部署）
1.8 部署机制检测
识别应用程序如何部署：
- GitOps（ArgoCD、Flux）
- 直接部署（Helm、kubectl）
- 手动部署
- 外部系统
对于GitOps：
- CI不得直接部署 - 它更新清单，GitOps控制器同步
- 确定是否存在GitOps资源（ArgoCD应用程序、Flux Kustomization）
- 如果没有，可能需要创建它们（相同仓库或独立集群配置仓库）
- 确定图像标签更新的清单位置
如果不清楚，在步骤2中询问用户。
1.9 工具管理器检测
检查现有工具/环境管理器（DevBox、mise、asdf等）。如果找到，自动使用它们。如果没有，将在交互式Q&A中询问用户。
步骤2: 呈现发现供确认
**在生成工作流前，呈现分析摘要。**仅包括与此项目相关的内容 - 以下示例是说明性的，不是填充的模板：
## 分析摘要
我分析了您的仓库并发现：
**语言/框架**：Node.js 20与Express
**构建命令**：`npm run build`（来自package.json）
**测试命令**：`npm test`（来自package.json）
**现有CI**：找到GitHub Actions工作流（ci.yml）
**应用定义**：`charts/myapp/`中的Helm图表
**部署机制**：使用ArgoCD的GitOps
这正确吗？您想改变什么吗？
用户可以：
- 确认发现 → 继续到工作流选择
- 纠正错误
- 澄清歧义
步骤3: 呈现工作流选择
**基于分析呈现与此项目相关的选择。**这些是需要用户输入的策略决策。仅询问适用的内容 - 例如，如果没有Dockerfile，不要询问容器注册表；如果是库，不要询问部署策略。
常见选择包括：
- PR工作流：拉取请求上应运行什么？
- 发布触发器：什么触发发布构建？
- 发布验证：发布工作流是否应重新运行在PR中已通过的检查？（重新运行所有 = 最安全/最慢，跳过验证 = 最快，仅安全扫描 = 折中）
- 容器注册表：在哪里推送图像？（如果容器化）
- 环境设置：原生GitHub Actions或DevBox？
- 部署策略：GitOps、直接或手动？（如果部署）
根据需要询问澄清问题：
- 如果分支策略不清楚：“您使用功能分支与拉取请求，还是直接推送到主分支？”
- 如果存在多个自动化选项：“我找到多种运行测试的方式。哪个是主要测试命令？”
- 如果检测到GitOps但仓库位置不清楚：“您的GitOps清单存储在哪里 - 相同仓库还是独立仓库？”
步骤4: 生成工作流
基于分析和确认用户选择生成适当工作流。
步骤5: 验证生成的工作流
在呈现给用户前：
- 语法验证：确保有效YAML和GitHub Actions语法
- 引用检查：验证引用的自动化存在
- 秘密文档：清晰列出所需秘密
- 权限检查：确保权限块最小
- 部署检查：验证部署步骤匹配所选机制
步骤6: 呈现给用户
提供：
- 生成的工作流文件，带解释性注释
- 摘要检测内容和所做决策
- 所需秘密配置（带设置指导）
- 所需权限和设置 - 基于工作流功能，识别需要什么权限或仓库设置，并提供配置指令。不要等待工作流失败 - 提前告诉用户要配置什么。
步骤7: 验证
用户批准后，遵循项目既定过程提交工作流。触发工作流，监控运行，并迭代任何失败直到通过。