setup-ci-automation

设置 CI 自动化

我负责项目的 CI：了解当前运行的任务，说明其用途，并添加新工作流，以便在仓库事件发生时自动执行 QA 任务。新工作流要做什么由负责该任务的技能决定——本技能负责正确地将其接入 CI。

关键约束

• 只能修改 CI 配置文件——不得修改源文件或测试文件。
• 绝不臆造作业要运行的命令——从负责该任务的技能或用户处获取命令内容。
• 最终结果必须通过 PR 提交 CI 配置——绝不能直接推送到默认分支。
• 密钥应存放在 CI 的密钥存储区，绝不能写入配置文件。

工作流

第 1 步 — 调查 CI

• 阅读仓库的 CI 配置文件，确定使用的 CI 系统；如果有多个或一个都没有，询问要使用哪一个。
• 梳理现有工作流：每个工作流的触发条件、作业和用途——新自动化必须融入现有配置，不能与现有内容重复或造成破坏。
• 记录此 CI 提供的功能：密钥存储、作业间和流水线间传递值、跨流水线触发器、部署事件。

第 2 步 — 用图示说明

如果环境支持渲染 Mermaid，请用流程图展示现有或拟议的工作流：触发条件 → 以动词开头的操作块 → 结果。决策使用菱形问句；配置详情写在图下方的文字中，不要放进流程块。

• 绝不能只发图示——后面要跟一段简短说明，介绍工作流的作用以及需要用户决定的事项。
• 拟议工作流的图示是审批关卡——用户接受之前，不得进行任何接线配置。

第 3 步 — 设计新工作流

• 明确触发事件、要运行的任务，以及任务结果的去向。
• 任务的命令由负责该任务的技能提供（下方列出一些示例）；本技能只负责 CI 接线。
• 如果任务由 AI Agent 执行，CI 必须能够运行该 Agent——❓询问项目如何在 CI 中运行 Agent；绝不要捏造安装方式。
• 在编写配置前，先用图示确认设计（第 2 步）。

第 4 步 — 编写工作流

• 根据当前 CI 使用其自身语法；绝不能照搬其他 CI 的文件结构。
• 每个作业只包含任务命令和 CI 原生功能——不要解析日志、添加 shell 严格模式前置语句，也不要用包装 bash 脚本包裹命令。
• 执行差异比较或遍历历史记录的作业，应使用 CI 检出的完整历史选项——不要手动运行 fetch 命令。
• 响应已合并变更的作业，应检出实际合入主线的确切修订版本——后续合并会使分支顶端不断变化。
• 自动化作业绝不能阻塞 PR，也绝不能导致合并或发布流水线失败。

第 5 步 — 配置密钥

• Testomat.io 项目 API 密钥：在 CI 的密钥存储区中以 TESTOMATIO_<project-slug> 为名存储，并映射到每个需要该密钥的作业中的 TESTOMATIO 环境变量。
• 明确告知用户应在哪里添加每个密钥——指出此 CI 在该仓库中使用的密钥存储位置，以及需要输入的确切名称。
• ❓请用户确认密钥已就位，再合并工作流的 PR——缺少密钥会导致首次运行失败。

第 6 步 — 通过 PR 交付

• 在分支上提交 CI 配置，并按照项目的常规流程创建 PR。
• PR 描述应包含工作流图示、自动化内容，以及审阅者在合并前必须配置的密钥或前置条件。
• 如果 CI 会从分支本身运行由 PR 触发的工作流，请指出此 PR 将会运行新工作流。

自动化构想

值得通过 CI 事件配置的任务——每项任务的内容由相应的技能负责：

事件	自动化	任务负责人
PR 打开	根据 PR 差异生成测试用例	pull-request-diff-analyzer + qa-write-test-cases
Issue 打开	对功能进行 QA 分析——边缘情况、验收标准	qa-thinking
部署完成	创建范围明确的测试运行，启动受影响的测试	setup-change-aware-pr-testing
定期触发	检测重复或重叠的测试用例	detect-duplicate-test-cases

相关技能

setup-change-aware-pr-testing（基于此技能构建的、由覆盖率驱动的 PR 测试工作流）、run-tests-with-testomatio-reporter（用于与测试运行相关任务的报告器命令）、testing-workflow（将 QA 任务分派给对应的技能）。