You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Chained execution — runner <install|run> ... taskA taskB taskC — is a flagship
feature, but when one task in a long chain fails (especially under --keep-going), the output gives no consolidated signal of which task failed
or why. Diagnosis means scrolling the whole interleaved log to find the one
error line hidden among passing/skipped output.
No end-of-run summary. After a chain there is no digest such as FAILED: test:bun (exit 1); passed: typecheck, test:corpus, …. The lone error: script "test:bun" exited with code 1 is buried in hundreds of lines.
Task headers carry no status.runner: <task> is printed before the
task runs and is never followed by a pass/fail/exit marker. A passing task
and a failing task look identical at the header level — you only learn the
outcome by spotting the underlying tool's own error line between two headers.
Aggregate exit code is unattributed. The chain exits 2 while the
failing task exited 1. No documented mapping from per-task codes to the
final code, so 2 explains nothing on its own.
Under --keep-going, run-vs-skipped-vs-failed counts are invisible
without reading the entire log.
Per-task outcome line after each task (✓/✗ <task> (exit N)), so headers
bracket the task instead of only preceding it.
Document the aggregate exit code (e.g. count of failed tasks, or first
non-zero) so a chain's exit code is interpretable.
CI attribution: when GITHUB_ACTIONS=true, emit ::error title=runner: <task>::exit N for each failed task so it lands in the Annotations panel.
(Group annotations already exist per CI group annotations from quiet run pollute stdout #86 — the gap here is failure
attribution + the summary, not grouping.)
Problem
Chained execution —
runner <install|run> ... taskA taskB taskC— is a flagshipfeature, but when one task in a long chain fails (especially under
--keep-going), the output gives no consolidated signal of which task failedor why. Diagnosis means scrolling the whole interleaved log to find the one
error line hidden among passing/skipped output.
Repro
A 7-task chain in CI:
Output (trimmed):
Why it's hard to diagnose
FAILED: test:bun (exit 1); passed: typecheck, test:corpus, …. The loneerror: script "test:bun" exited with code 1is buried in hundreds of lines.runner: <task>is printed before thetask runs and is never followed by a pass/fail/exit marker. A passing task
and a failing task look identical at the header level — you only learn the
outcome by spotting the underlying tool's own error line between two headers.
2while thefailing task exited
1. No documented mapping from per-task codes to thefinal code, so
2explains nothing on its own.--keep-going, run-vs-skipped-vs-failed counts are invisiblewithout reading the entire log.
Proposed
End-of-run summary for any multi-task run (not just
--keep-going): oneline per task with status + exit code (+ duration, cf. Per-task execution timing in chain mode (sequential + parallel) #58), e.g.
Per-task outcome line after each task (
✓/✗ <task> (exit N)), so headersbracket the task instead of only preceding it.
Document the aggregate exit code (e.g. count of failed tasks, or first
non-zero) so a chain's exit code is interpretable.
CI attribution: when
GITHUB_ACTIONS=true, emit::error title=runner: <task>::exit Nfor each failed task so it lands in the Annotations panel.(Group annotations already exist per CI group annotations from quiet run pollute stdout #86 — the gap here is failure
attribution + the summary, not grouping.)
Related
natural home for that timing.
annotation noise rather than which-task-failed reporting.