Testany Pipeline

Testany Pipeline

本 skill 通过 Testany MCP 工具管理 Testany 平台上的 pipeline。 所有操作都是对 Testany 平台的远程 API 调用，不涉及本地文件系统。

关键前提：

• pipeline 是 Testany 的执行与编排单元
• Testany 不支持直接执行单条 case
• trigger 只是 pipeline 的执行入口，不是编排层

用户输入: $ARGUMENTS

---

宿主能力适配

• 优先使用宿主提供的结构化提问工具（如 AskUserQuestion）一次性收集缺失信息。
• 如果宿主不支持该工具，则用一条普通消息集中提问相同问题；低风险字段可给出默认值建议。
• 如果宿主支持 slash command，可推荐相关 workflow 的命令入口；否则直接在当前线程继续对应 workflow。

---

先统一心智模型

使用本 skill 前，先按 automation-model.md 理解边界：

• 上游给出的通常是 traditional test scenario
• testany-case-writing 负责把它拆成 platform cases
• 本 skill 负责把这些 platform cases 编排成 pipeline
• testany-trigger 负责为 pipeline 配置 Plan / Manual Trigger / Gatekeeper

重要结论：

• 本 skill 的主输入不应该是“让我从 case 描述里猜业务流程”
• 本 skill 的主输入应该是上游明确给出的 automation design / decomposition

---

上游输入优先级

按以下优先级选择输入模式：

1. Primary：automation design / decomposition

• 来自 testany-case-writing
• 最好是基于 approved Test Spec 的 Testany Automation Handoff 生成
• 已明确 case inventory、依赖关系、relay map、是否有分支

2. Secondary：用户明确给出的 case keys + 依赖描述

• 例如“用 A1B2C3D4 先登录，再用 E5F6A7B8 查询”

3. Fallback：从现有 case metadata 反推

• 只在前两者都没有时使用
• 必须把结果回显给用户确认
• 不能把“猜出来的流程”当主路径

---

操作速查

---

Create（创建）

Phase 0: 先判断输入模式

Primary：已有 automation design / decomposition

如果上游已给出以下内容，直接按它编排：

• platform case inventory
• 每个 case 的职责
• source_case_ids / scenario_group（若来自 Test Spec handoff）
• dependencies
• relay map
• 是否有 whenFailed / expect: fail

Secondary：用户已明确给出 case keys 与顺序

如果用户直接给出：

• case keys
• 执行顺序
• relay 关系

则直接进入 YAML 构建。

Fallback：只能从现有 cases 反推

仅在没有上游 design 时使用：

• testany_list_cases / testany_get_case
• 结合 case_labels、description、environment_variables[].description
• 给出候选编排方案
• 必须让用户确认

---

Phase 1: 准备数据

并行获取：

• testany_get_my_workspaces
• testany_list_cases 或 testany_list_my_cases

如果用户还没有把 platform cases 注册到 Testany 平台：

• 停止创建 pipeline
• 提示先走 testany-case

---

Phase 2: 构建 pipeline 设计

根据输入模式，确定：

• pipeline 名称
• 所属 workspace
• 包含哪些 case keys
• 顺序与前置依赖
• relay 变量关系
• 是否有失败分支
• 是否存在 expect: fail

何时使用 case_keys

仅当满足以下条件时，允许直接用 case_keys 自动生成简单顺序 pipeline：

• 无条件分支
• 无 relay
• 无 expect: fail
• 用户只要最简单的顺序执行

何时必须手写 YAML

出现以下任一情况时，必须显式生成 YAML：

• 有 relay
• 有 whenPassed / whenFailed
• 有 expect: fail
• 需要表达分支、前置、清理或失败路径

---

Phase 3: 验证 relay 与依赖

如有 relay，必须： 1. testany_get_case 检查源 case 是否有 type='output' 变量 2. testany_get_case 检查目标 case 是否有 type='env' 变量 3. 确保源 case 在 rules 中位于目标 case 之前 4. 确保 relay 不与 whenFailed 组合 5. 禁止把 `type='secrets'` 行作为 relay 源或目标：secrets 的值来自 workspace Credential Safe，不经过 relay 传递；目标端也不能被 relay 覆写。如果 relay 源/目标命中 secrets 行，停下来向用户说明并请求改用 env 或 output 行

---

Phase 4: 创建 pipeline

调用 testany_create_pipeline：

---

Phase 5: 验证

调用 testany_verify_pipeline：

• 检查 kind 是否在支持范围内（rule/v1.2 或 rule/v1.3）
• 检查 rules 结构是否合法
• 检查 relay 与依赖约束

---

Fallback：从现有 cases 反推（仅兜底）

当且仅当前两种输入模式都不存在时，才允许从现有 cases 反推。

可用于判断的信息

禁止猜测

如果仍然无法确定：

• 哪些 cases 应被包含
• 顺序如何安排
• relay 如何配置

必须向用户确认，而不是猜测。

---

Read（查询）

---

Update（更新）

可更新的字段

更新流程

1. testany_get_pipeline 读取当前配置 2. testany_get_pipeline_yaml 读取当前 YAML（如需修改编排） 3. 优先按已有 automation design 更新，而不是现场重猜 4. 如修改 YAML，重新验证 relay 与依赖 5. testany_update_pipeline 提交更新

---

Delete（删除）

删除前必须检查引用情况： 1. testany_get_pipeline_used_by 2. 如被 Plan / Manual Trigger / Gatekeeper 引用，先提示用户解除引用 3. 无引用后再删除

警告：此操作不可撤销。

---

常见问题处理

---

返回格式

任务完成后，向用户汇报：

• Pipeline Key
• Pipeline 名称
• 所属工作空间
• 来源输入模式：automation design / explicit case keys / fallback inference
• 包含的 case 数量与顺序
• relay 配置摘要
• 是否建议继续到 testany-trigger
• 如已发起执行，是否建议继续到 testany-execution

---

参考文档

• Testany 自动化对象模型
• Pipeline YAML 语法
• Pipeline 相关概念

Testany 核心概念（Pipeline 相关）

Pipeline（流水线）

定义：编排多个 case 的执行与编排单元

属性：

• pipeline_key: 格式为 {WS_KEY}-{4-5位大写十六进制}（如 Y2K-0601、Y2K-0001A）
• name: 流水线名称
• description: 描述
• definition: YAML 格式的执行规则定义
• case_keys: 关联的 case key 列表
• environments: 环境标签列表
• creator: 创建者（不可更新）
• owned_by: 所有者（可通过更新转移）
• pipeline_labels: Pipeline 标签列表

Pipeline 支持依赖关系（whenPassed/whenFailed）、变量传递（relay）和 expect: fail。

说明：

• Testany 平台执行的是 Pipeline，而不是单条 Case。
• 即使只有一个 Case，要真正执行也仍然需要一条 Pipeline。

---

Case（测试用例）

定义：Testany 平台上的可复用原子自动化步骤包

属性：

• case_key: 8 位大写十六进制标识符（如 A1B2C3D4）
• name: 用例名称
• case_meta: 执行配置（trigger_method, environment_variables）

Pipeline 通过 case_key 引用 case。

说明：

• Case 不等同于传统测试语义中的完整测试场景。
• 一个传统测试场景可能会拆成多个 Cases，再由 Pipeline 编排。

---

Execution（执行）

定义：一次测试运行的实例

属性：

• execution_id: 格式为 {pipeline_key}-{5位大写十六进制}（如 Y2K-0601-0000A）
• status: 执行状态

---

Workspace（工作空间）

定义：资源隔离和权限控制单元

属性：

• workspace_key: 3 位大写字母数字（如 Y2K）
• Pipeline Key 的前缀来自所属 workspace

---

执行状态码

Pipeline YAML 语法

基本结构

kind: rule/v1.3
spec:
  rules:
    - run: 'A1B2C3D4'           # 第一个 case（无依赖）
    - run: 'E5F6A7B8'
      whenPassed: 'A1B2C3D4'    # 仅当 A1B2C3D4 通过时执行
      relay:
        - key: AUTH_TOKEN       # 本 case 中接收变量名
          refKey: A1B2C3D4/TOKEN  # 来源：case_key/变量名
          nonSecret: true

---

Rule 字段说明

---

依赖规则

1. 互斥约束：whenPassed 和 whenFailed 不能同时出现 2. DAG 约束：被引用的 case 必须在 rules 数组中之前定义 3. 单依赖约束：每个 rule 只能依赖一个 case

---

Relay（变量传递）

Relay 字段

Relay 约束（重要）

配置 relay 时，必须先查询 case 定义来验证环境变量：

验证流程:
1. testany_get_case 获取 run 对应的 case
   → 检查 case_meta.environment_variables
   → relay.key 必须存在且 type='env'

2. testany_get_case 获取 refKey 中的源 case
   → 检查 case_meta.environment_variables
   → refKey 中的变量必须存在且 type='output'

---

常见编排模式

顺序执行（无依赖）

kind: rule/v1.3
spec:
  rules:
    - run: 'A1B2C3D4'
    - run: 'E5F6A7B8'
    - run: 'C9D0E1F2'

链式依赖

kind: rule/v1.3
spec:
  rules:
    - run: 'A1B2C3D4'  # Login
    - run: 'E5F6A7B8'
      whenPassed: 'A1B2C3D4'  # Get Profile（需要登录成功）
    - run: 'C9D0E1F2'
      whenPassed: 'E5F6A7B8'  # Update Profile（需要获取成功）

带 Relay 的链式

Case A (04E41DDE) 的 environment_variables:

[{ "name": "TOKEN", "type": "output", "value": "" }]

Case B (FAFC249A) 的 environment_variables:

[{ "name": "AUTH_TOKEN", "type": "env", "value": "" }]

Pipeline YAML:

kind: rule/v1.3
spec:
  rules:
    - run: '04E41DDE'  # Login → 输出 TOKEN
    - run: 'FAFC249A'
      whenPassed: '04E41DDE'
      relay:
        - key: AUTH_TOKEN        # ✓ FAFC249A 中 type='env'
          refKey: 04E41DDE/TOKEN # ✓ 04E41DDE 中 type='output'
          nonSecret: true

失败后执行（清理场景）

kind: rule/v1.3
spec:
  rules:
    - run: 'A1B2C3D4'  # Main test
    - run: 'C1EA2E01'  # Cleanup case
      whenFailed: 'A1B2C3D4'  # 仅当主测试失败时执行清理

---

Schema Reference

在创建或更新 pipeline 前，可读取 MCP Resource 获取完整 schema：

URI: testany://schema/pipeline
Method: resources/read