Overview

7 days30 days

Latest CI Pipeline Executions

Fuzzy

Succeeded
35617
d418f5a6 fix(core): emit cursor-hide on TUI task finalization regardless of PTY state [Self-Healing CI Rerun]
by nx-cloud[bot]
Failed
35617
Flaky task→
6d99b0e1 chore(core): test that append_task_output does not hide the cursor Pins the negative half of the streaming/finalize contract: while chunks are still arriving via append_task_output, the cursor must remain visible. Only print_task_terminal_output (called at end of life) hides the cursor.
by Jason Jean
Failed
35617
Flaky task→
2006e6ea fix(core): emit cursor-hide on TUI task finalization regardless of PTY state The TS-side ordering swap that fixed double-logged batch terminal output also moved batch tasks from the no-PTY branch of `print_task_terminal_output` (which appended `\x1b[?25l`) to the PTY-exists branch (which previously returned early). Finished batch panes ended up showing a blinking virtual cursor at the end of the captured output. Make `print_task_terminal_output` emit the cursor-hide escape on both branches: the no-PTY branch keeps writing `output + cursor-hide` when it creates the PTY, and the PTY-exists branch now writes only the cursor-hide. The escape is idempotent so it's safe regardless of how the PTY's content got there. Two unit tests pin the contract — verified to fail without the fix: - batch-style flow (append creates the PTY, print finalizes) - cache-hit flow (print creates the PTY)
by Jason Jean
Canceled
35617
2006e6ea fix(core): emit cursor-hide on TUI task finalization regardless of PTY state The TS-side ordering swap that fixed double-logged batch terminal output also moved batch tasks from the no-PTY branch of `print_task_terminal_output` (which appended `\x1b[?25l`) to the PTY-exists branch (which previously returned early). Finished batch panes ended up showing a blinking virtual cursor at the end of the captured output. Make `print_task_terminal_output` emit the cursor-hide escape on both branches: the no-PTY branch keeps writing `output + cursor-hide` when it creates the PTY, and the PTY-exists branch now writes only the cursor-hide. The escape is idempotent so it's safe regardless of how the PTY's content got there. Two unit tests pin the contract — verified to fail without the fix: - batch-style flow (append creates the PTY, print finalizes) - cache-hit flow (print creates the PTY)
by Jason Jean
Succeeded
35617
9ac067cb chore(core): simplify batch task result handling Apply review cleanup: - Extract `resolveBatchTaskStatus` helper in task-orchestrator instead of repeating `result.status ?? (result.success ? 'success' : 'failure')` in two spots. - Skip `printTaskTerminalOutput` for skipped batch tasks with no terminal output — otherwise the TUI allocates a per-task PTY just to write a cursor-hide escape, which scales linearly with skipped peers in large batches. - Move maven `emitResult` for cascaded skips out of the graph `synchronized` block — JSON serialization and stderr I/O don't need the graph monitor and would otherwise stall every other worker on cascading failures. Skipped-task results are collected locally and emitted after the lock is released. - Drop the redundant "Kotlin runner emits NX_RESULT" preamble comment in both TS executor files. - Drop `= 0` defaults from Maven `TaskResult` factory startTime/endTime params — every real call site passes both, and the default would silently produce zero-duration tasks. - Reword the `TaskResult.status` doc-comment to call out that it's the contract for batch executors, not an opt-in escape hatch.
by Jason Jean
Failed
35617
Fix applied→
3b0397d6 chore(gradle): require explicit status on Kotlin TaskResult Drop the silent default on `TaskResult.status` and add `success`, `failure`, `skipped`, `fromBoolean` factory functions. Every call site is now explicit about the outcome it represents, and the TS side can drop the `data.result.status ?? …` defensive fallback — the runner always sends `status` on the wire. Same shape for the Maven runner. Also tightens stale comments throughout the diff.
by Jason Jean
Canceled
35617
4a666523 fix(maven): don't yield fallbacks for unyielded tasks on clean exit CI surfaced a regression in the maven batch e2e test: the previous post-loop fallback yielded a `failure` result for any unyielded task, which prevented Nx's task-orchestrator from retrying tasks that the batch runner failed to report on. The Maven batch runner's stderr can interleave concurrent task output such that one task's NX_RESULT line ends up captured inside another task's terminalOutput string, leaving the inner task unyielded on the TS side. With a clean exit code, Nx's retry loop is the right recovery path — yielding a fallback failure here turns a transient parser miss into a permanent failure. The catch-block fallback (for non-zero exit codes) is preserved so real maven failures still get the skipped/failed peer treatment.
by Jason Jean
Canceled
35617
4a666523 fix(maven): don't yield fallbacks for unyielded tasks on clean exit CI surfaced a regression in the maven batch e2e test: the previous post-loop fallback yielded a `failure` result for any unyielded task, which prevented Nx's task-orchestrator from retrying tasks that the batch runner failed to report on. The Maven batch runner's stderr can interleave concurrent task output such that one task's NX_RESULT line ends up captured inside another task's terminalOutput string, leaving the inner task unyielded on the TS side. With a clean exit code, Nx's retry loop is the right recovery path — yielding a fallback failure here turns a transient parser miss into a permanent failure. The catch-block fallback (for non-zero exit codes) is preserved so real maven failures still get the skipped/failed peer treatment.
by Jason Jean
Succeeded
35617
4a666523 fix(maven): don't yield fallbacks for unyielded tasks on clean exit CI surfaced a regression in the maven batch e2e test: the previous post-loop fallback yielded a `failure` result for any unyielded task, which prevented Nx's task-orchestrator from retrying tasks that the batch runner failed to report on. The Maven batch runner's stderr can interleave concurrent task output such that one task's NX_RESULT line ends up captured inside another task's terminalOutput string, leaving the inner task unyielded on the TS side. With a clean exit code, Nx's retry loop is the right recovery path — yielding a fallback failure here turns a transient parser miss into a permanent failure. The catch-block fallback (for non-zero exit codes) is preserved so real maven failures still get the skipped/failed peer treatment.
by Jason Jean
Failed
35617
Environment issue→
e09ba7c6 chore(gradle): drop ResultEmitter unit tests Reverts 39f7401bb8. These tests pinned the NX_RESULT protocol shape but didn't exercise any code changed in this PR — keeping them only as scaffolding wasn't worth the maintenance surface.
by Jason Jean
Failed
35617
Fix available→
df37d8e8 chore(gradle): test skipped peer behavior in gradle batch executor Adds tests that mock the batch-runner JAR's spawn and verify: - When a sibling reports failure and the runner exits non-zero, unyielded peers are emitted with `status: 'skipped'` and an empty terminalOutput. - When the runner exits non-zero with no per-task results, all peers fall back to `failure` (no skipped status), since there is no observed sibling failure to attribute the skip to. - Successful results pass through unchanged. Equivalent tests added for the Maven batch executor.
by Jason Jean
Canceled
35617
df37d8e8 chore(gradle): test skipped peer behavior in gradle batch executor Adds tests that mock the batch-runner JAR's spawn and verify: - When a sibling reports failure and the runner exits non-zero, unyielded peers are emitted with `status: 'skipped'` and an empty terminalOutput. - When the runner exits non-zero with no per-task results, all peers fall back to `failure` (no skipped status), since there is no observed sibling failure to attribute the skip to. - Successful results pass through unchanged. Equivalent tests added for the Maven batch executor.
by Jason Jean
Failed
35617
df37d8e8 chore(gradle): test skipped peer behavior in gradle batch executor Adds tests that mock the batch-runner JAR's spawn and verify: - When a sibling reports failure and the runner exits non-zero, unyielded peers are emitted with `status: 'skipped'` and an empty terminalOutput. - When the runner exits non-zero with no per-task results, all peers fall back to `failure` (no skipped status), since there is no observed sibling failure to attribute the skip to. - Successful results pass through unchanged. Equivalent tests added for the Maven batch executor.
by Jason Jean
Canceled
35617
3f3b31b2 fix(maven): mark batch peers as skipped after a sibling fails Mirrors the Gradle batch executor: when a Maven task fails or the batch runner exits non-zero, peers that never got to run are now reported with `status: 'skipped'` and an empty terminalOutput instead of `failure` with a generic error message.
by Jason Jean
Failed
35617
Flaky task→
3f3b31b2 fix(maven): mark batch peers as skipped after a sibling fails Mirrors the Gradle batch executor: when a Maven task fails or the batch runner exits non-zero, peers that never got to run are now reported with `status: 'skipped'` and an empty terminalOutput instead of `failure` with a generic error message.
by Jason Jean