| name | testany-execution |
| description | Testany execution 观测与管理 - 查看进度、查询历史、刷新状态、取消未开始执行、将失败执行交给 debug |
| argument-hint | [execution_key / pipeline_key / 操作]，如：查看 Y2K-0601-0000B、看最近失败、取消一个 pending execution |
Testany Execution Operations
管理 Testany 平台上的 execution，包括进度观测、历史查询、状态刷新、取消和失败交接。
用户输入: $ARGUMENTS
先统一心智模型
在开始之前，先按 automation-model.md 理解边界：
pipeline 是执行与编排单元trigger 负责“怎么发起执行”，包括长期入口和即时运行- 本 skill 负责“执行发起之后怎么管理 execution”
- 失败 execution 的根因分析属于
testany-debug
重要结论：
- 本 skill 不负责创建 Plan / Manual Trigger / Gatekeeper
- 本 skill 也不负责即时发起一次执行；这属于
testany-trigger
- 本 skill 关注 execution lifecycle：看、查、刷、停、交接
职责范围
- 查看 execution 详情与 case 级结果
- 列出/搜索 execution 历史
- 刷新 execution 状态
- 轮询等待 execution 进入终态
- 取消尚未开始的 execution
- 汇总执行结果并决定是否转给
testany-debug
- 在需要时获取 execution case 详情与日志签名入口
操作速查
| 用户意图 | 操作类型 | MCP 工具 |
|---|
| 列出执行记录 | Read | testany_list_executions |
| 查看执行详情 | Read | testany_get_execution |
| 查看某个 case 在执行中的详情 | Read | testany_get_execution_case |
| 刷新执行状态 | Update | testany_refresh_execution |
| 取消未开始执行 | Update | testany_cancel_execution |
| 获取工作空间执行状态汇总 | Read | testany_get_workspace_execution_status |
| 获取可筛选状态值 | Read | testany_filter_execution_status |
| 获取有执行记录的 pipelines | Read | testany_filter_execution_pipelines |
| 获取日志签名 | Read | testany_log_sign |
核心知识
执行状态
| 状态 | 值 | 含义 | 是否终态 |
|---|
| NOT_STARTED | -1 | 未开始/排队中（等待并发槽位） | 否 |
| RUNNING | 0 | 执行中 | 否 |
| SUCCESS | 1 | 全部通过 | 是 |
| FAILURE | 2 | 有失败 | 是 |
| SKIPPED | 3 | 跳过（仅 Case） | 是 |
| FAIL_AS_EXPECTED | 4 | 预期失败（仅 Case） | 是 |
| CANCELLED | 5 | 已取消 | 是 |
| ERROR | 99 | 系统错误 | 是 |
Workspace 队列状态
Testany 使用 workspace 级并发槽位（Redis semaphore）控制 execution 并行度。通过 testany_get_workspace_execution_status 可获取：
| 字段 | 含义 |
|---|
limit | workspace 并发上限（Community=2, Paid=4, Enterprise=8，可调） |
claimed | 正在执行的 execution key 列表（已占据槽位） |
pending | 排队中的 execution key 列表（等待槽位） |
当用户的 execution 状态为 NOT_STARTED 且长时间不变时，应主动查询队列状态：
claimed 数量 = limit → 槽位已满，该 execution 在 pending 中排队claimed 中有长时间运行的旧 execution → 旧执行占住了槽位
当用户问"为什么我的 execution 不跑"时，这是第一个要检查的方向，优先于检查 YAML 和 relay。
本 skill 的标准处理链
trigger 已返回 execution_key
-> testany_get_execution / testany_refresh_execution
-> 状态进入终态
-> 如失败，按需 testany_get_execution_case / testany_log_sign
-> 必要时交给 testany-debug
典型工作流
1. 查看单次执行进度
适用输入：
execution_key- “看这次执行跑到哪了”
处理方式：
testany_get_execution- 如状态不新鲜或用户要求刷新，
testany_refresh_execution
- 汇报当前状态、开始时间、通过/失败数量
2. 轮询等待执行完成
适用输入：
- “帮我盯着这次执行直到结束”
- 已知
execution_key
处理方式：
testany_get_execution- 若未终态，则循环
testany_refresh_execution
- 直到进入终态或达到超时上限
轮询建议：
- 初始间隔：5 秒
- 最大间隔：30 秒
- 默认超时：10-30 分钟，按 pipeline 复杂度调整
3. 查看历史执行
适用输入：
- “看最近失败的执行”
- “列出某个 pipeline 的最近执行”
- “看某个 workspace 的执行情况”
处理方式：
- 视条件调用
testany_filter_execution_status / testany_filter_execution_pipelines
testany_list_executions- 必要时再
testany_get_execution
常用过滤维度：
workspacepipeline_keystatustriggered_byenvexe_start_time_from / exe_start_time_to
4. 取消 execution
适用输入：
处理方式：
testany_get_execution- 仅当状态仍是未开始 / pending 时，调用
testany_cancel_execution
- 如果已经开始运行，明确告知不能取消
5. 查看队列状态 / 诊断 execution 排队
适用输入：
- "为什么我的 execution 不跑"
- "YAML 是并行的但执行串行了"
- "看一下队列状态"
- "execution 一直 NOT_STARTED"
处理方式：
testany_get_workspace_execution_status → 获取 limit / claimed / pending- 判断并报告：
- claimed 数量是否 = limit（槽位满）
- 用户关注的 execution 是否在 pending 列表中
- claimed 中是否有长时间运行的旧 execution 占住槽位
- 如果槽位未满但 case 仍串行执行：
- 提示用户检查 pipeline YAML 版本（rule/v1.2 不支持 case 级并行）
- 建议查看 case 的 start_time/finish_time 确认是否被串行调度
- 如需深入分析，切到
testany-debug（调度/队列诊断分支）
6. 将失败执行交给 debug
适用输入：
- “这个执行为什么失败”
- “帮我定位失败 case”
处理方式：
testany_get_execution- 找出失败 case
- 如只需要定位，先
testany_get_execution_case
- 如需要根因分析与日志解读，切到
testany-debug
边界澄清
什么时候去 testany-trigger
以下场景不属于本 skill：
- 现在立刻执行一次 pipeline
- 给 pipeline 配 Plan
- 创建 Manual Trigger
- 创建 Gatekeeper
这些都应切到 testany-trigger。
什么时候去 testany-debug
以下场景应转给 testany-debug：
- 用户要看失败根因
- 用户要读取与分析日志
- 用户要判断是断言失败、超时、依赖错误还是基础设施问题
返回格式
任务完成后，向用户汇报：
- Execution Key（如
Y2K-0601-0000B）
- 所属 Pipeline
- 当前状态或终态结果
- 通过/失败/跳过数量
- 失败 case 列表（如有）
- 是否可取消 / 是否已取消
- 下一步建议：
- 需要继续触发执行 → 去
testany-trigger
- 需要分析失败原因 → 去
testany-debug
参考文档
