nx-cloud-ci-failure-review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Nx Cloud CI failure review

Nx Cloud CI 失败审查

Requires the

nx-cloud-api

skill for all Nx Cloud reads. This workflow is read-only.

Reduce failed pipelines to a small set of diagnostic groups. A failed pipeline does not prove that an agent or platform caused the failure. Classify each group only at the level the evidence supports.

所有 Nx Cloud 读取操作都需要

nx-cloud-api

skill。此 workflow 为只读。

将失败的流水线归并为少量诊断分组。流水线失败并不能证明故障由 agent 或平台引起。仅在证据支持的层级对每个分组进行分类。

Scope and collection

范围与收集

Use focused investigation mode when the user supplies one or more CIPE or run-group links. Fetch those exact records first. Follow their returned run-group, run, task, and workflow links. Compare the supplied executions directly. Do not run a broad time window or build a workspace-wide ranking unless the user asks for recurrence or scope. Keep cancellations that follow the named critical error as consequences, not separate root-cause groups.

Use review mode when the user asks for a workspace failure review. Review failures from the last 24 hours by default. CIPE and run-group list filters use

createdAt

, not failure time. Query a 30-hour creation window to cover the maximum normal six-hour CI duration. State the intended 24-hour review period and the 30-hour creation window.

Query

statuses=FAILED

statuses=TIMED_OUT

, and

statuses=CANCELED

. State the branches, CI contexts, statuses, endpoints, and record counts. Ask before widening the window or mixing unrelated repositories/workspaces.

Use nx-cloud-api for every read. Inspect the live schemas for

cipes

run-groups

run-groups/{runGroupId}

runs

runs/{runId}/tasks

, and the linked

steps

and

instances

endpoints. The public API has no separate workflow routes. Start with supplied CIPEs in focused investigation mode. Start with failed CIPEs and their linked run groups in review mode. Use only live documented filters and fields. Fetch one narrow page first and check pagination metadata before continuing.

Collect in this order:

Failed, timed-out, and canceled CIPEs with status, timestamps, branch, and CI context. Follow cursors to the end before a workspace-wide group ranking.
Linked run groups and their documented critical-error fields.
Runs and terminal task rows for each selected group.
Workflow and instance status only when task data does not explain the group.
The smallest relevant task or instance log excerpt for representative cases.

Use a semaphore of at most five narrow detail requests. Fetch logs only after a group reaches the top five. Tell the user before reading CI log content. Quote only redacted error lines.

Treat cancellations as their own category until their reason and timing show that they belong elsewhere. Do not call a cancellation a failure without that context.

当用户提供一个或多个 CIPE 或 run group 链接时，使用 focused investigation mode。首先获取这些精确记录。沿其返回的 run group、run、task 和 workflow 链接继续追踪。直接对比所提供的执行记录。除非用户要求分析重复性或范围，否则不要查询宽泛的时间窗口，也不要建立 workspace 范围的排名。将紧随已指明 critical error 之后发生的 cancellation 视为后果，而不是独立的根因分组。

当用户要求 workspace 失败审查时，使用 review mode。默认审查最近 24 小时内的失败。CIPE 和 run group 列表 filter 使用

createdAt

，而不是失败时间。查询 30 小时的创建窗口，以覆盖正常情况下最长 6 小时的 CI 持续时间。说明拟审查的 24 小时区间以及 30 小时创建窗口。

查询

statuses=FAILED

、

statuses=TIMED_OUT

和

statuses=CANCELED

。说明分支、CI context、状态、endpoint 和记录数量。在扩大窗口或混合无关的 repository/workspace 前，先征得用户同意。

所有读取操作都使用 nx-cloud-api。检查

cipes

、

run-groups

、

run-groups/{runGroupId}

、

runs

、

runs/{runId}/tasks

以及关联的

steps

和

instances

endpoint 的实时 schema。公共 API 没有单独的 workflow 路由。在 focused investigation mode 中，从所提供的 CIPE 开始。在 review mode 中，从失败的 CIPE 及其关联的 run group 开始。仅使用实时文档中列出的 filter 和 field。首先获取范围较小的一页，并检查分页元数据，然后再继续。

按以下顺序收集：

失败、timeout 和 canceled 的 CIPE，并记录状态、时间戳、分支和 CI context。在进行 workspace 范围的分组排名前，跟随 cursor 读取至末尾。
关联的 run group 及其有文档记录的 critical error 字段。
每个所选分组的 run 和终态 task 行。
仅当 task 数据无法解释该分组时，才检查 workflow 和 instance 状态。
为代表性案例获取最小相关 task 或 instance 日志摘录。

使用信号量，最多同时发起五个小范围详情请求。仅在某个分组进入前五名后获取日志。读取 CI 日志内容前先告知用户。仅引用已脱敏的错误行。

在 cancellation 的原因和时间表明其应归入其他分类之前，始终将其视为独立分类。没有相关上下文时，不要将 cancellation 称为失败。

Grouping method

分组方法

Build groups from stable evidence. Prefer a task identifier plus normalized error signature. Normalize timestamps, GUIDs, retry counters, temporary paths, and random ports. Keep stack context, command, and error code that distinguish two otherwise similar messages.

Use these categories only when their evidence exists:

Repeated task error.
Task timeout.
Cancellation.
Workflow or agent failure.
Unknown pipeline failure.

Call a group workflow or agent failure only when workflow/instance status, critical error, or agent evidence supports it and no task failure explains the pipeline. Do not infer infrastructure from the absence of a task log.

Reconcile the full pipeline picture before classification. A task can record

SUCCEEDED

or a cache hit while the main job fails during artifact download, validation, or restoration. Compare the run-group

criticalErrorMessage

, task status, cache status, workflow status, and later cancellations. In that case, classify the main-job cache restoration error as primary and the canceled runs as consequences.

For every group, record its CIPE count, run-group count, affected task count, first and last occurrence, branches/contexts, and one or two representative IDs. Rank first by affected pipeline count, then recurrence, then blocked duration when it is documented.

基于稳定证据建立分组。优先使用 task 标识符与规范化错误签名组合。规范化时间戳、GUID、重试计数器、临时路径和随机端口。保留能够区分两条相似消息的 stack 上下文、命令和错误码。

仅在存在相应证据时使用以下分类：

重复 task 错误。
Task timeout。
Cancellation。
Workflow 或 agent 故障。
未知流水线故障。

仅当 workflow/instance 状态、critical error 或 agent 证据支持该判断，并且没有 task failure 可以解释该流水线时，才将分组称为 workflow 或 agent 故障。不得因为缺少 task 日志就推断为基础设施问题。

分类前，先核对完整的流水线情况。task 可能记录为

SUCCEEDED

或命中 cache，而主 job 会在 artifact 下载、验证或恢复期间失败。对比 run group 的

criticalErrorMessage

、task 状态、cache 状态、workflow 状态以及后续 cancellation。在这种情况下，将主 job 的 cache 恢复错误归为主要原因，并将被取消的 run 视为后果。

对每个分组，记录其 CIPE 数量、run group 数量、受影响 task 数量、首次和末次出现时间、分支/context，以及一到两个代表性 ID。排序时先按受影响的流水线数量，再按重复性，最后按有文档记录的阻塞时长。

Next action rules

后续操作规则

Repeated task error: when a relevant workspace checkout exists, inspect
```
CODEOWNERS
```
and project ownership metadata at the recorded commit. Suggest a likely review owner. Do not assign work or claim ownership when that evidence is absent.
Task timeout: compare duration and resource evidence. Request a focused reproduction or resource report when it does not show a direct cause.
Cancellation: identify the documented cancel source, or keep it separate as unknown cancellation.
Workflow or agent failure: retry or monitor only when the evidence supports a transient event. Otherwise inspect the named workflow/agent asset.
Unknown: request the smallest log or run detail that can separate the cases.

Do not make code, workflow, or allocation changes without explicit approval.

重复 task 错误：如果存在相关的 workspace checkout，请检查已记录 commit 处的
```
CODEOWNERS
```
和项目所有权元数据。指出可能的审查负责人。没有这些证据时，不要分配工作，也不要声称所有权。
Task timeout：对比持续时间和资源证据。如果证据未显示直接原因，请请求聚焦复现或资源报告。
Cancellation：确定有文档记录的取消来源；否则将其单独保留为 unknown cancellation。
Workflow 或 agent 故障：仅在证据支持瞬态事件时重试或监控；否则检查指定的 workflow/agent asset。
Unknown：请求能够区分各类情况的最少日志或 run 详情。

未经明确批准，不要进行代码、workflow 或资源分配变更。

Report format

报告格式

undefined

undefined

Failed CI review

Scope

Window: …
Data: …

Window: …
Data: …

Failure groups

1. <evidence-level category> — <short signature>

Confirmed facts: affected CIPEs/runs/tasks; representative IDs; log excerpt.
Assessment: Confirmed / Likely / Needs diagnostic run — …
Impact: …
Highest-leverage next action: …

Confirmed facts: affected CIPEs/runs/tasks; representative IDs; log excerpt.
Assessment: Confirmed / Likely / Needs diagnostic run — …
Impact: …
Highest-leverage next action: …

Unclassified or incomplete data


Limit a review report to five groups. In focused investigation mode, report the
supplied executions as one comparison when they have the same normalized signature. Link each
finding to exact CIPEs, run groups, runs, and tasks where available. State the data
limit when pagination, missing assets, or missing context affects the conclusion.


将审查报告限制为最多五个分组。在 focused investigation mode 中，如果所提供的执行记录具有相同的规范化签名，则将其作为一次对比进行报告。在可用时，将每项发现关联到精确的 CIPE、run group、run 和 task。当分页、资产缺失或上下文缺失影响结论时，说明数据限制。