results

crabbox results prints the structured test summary attached to a recorded run. It answers "did the suite pass, and which cases failed?" without making you page through the raw command log.

# Record a run, then read its results.
crabbox run --junit junit.xml -- go test ./...
crabbox results run_abcdef123456
crabbox results run_abcdef123456 --failed-only
crabbox results run_abcdef123456 --json

The run id is accepted as a positional argument or via --id. A coordinator must be configured (CRABBOX_COORDINATOR or config set-broker), because results are read back from the recorded run, not from the live box.

#How results get attached

Results are attached only when crabbox run knows where to find remote JUnit XML after the command exits. There are three ways to point it at the files.

On the command line:

crabbox run --junit junit.xml -- <command...>
crabbox run --junit junit.xml,reports/junit.xml -- <command...>

In repo config:

results:
  junit:
    - junit.xml
    - reports/junit.xml

Or let run scan common JUnit locations after the command:

crabbox run --results-auto -- <command...>

results:
  auto: true

You can also set CRABBOX_RESULTS_JUNIT (comma-separated paths) in the environment.

After the command finishes, the CLI reads each remote file from the workdir, parses the JUnit XML, and sends only the parsed summary to the coordinator. Raw XML is never stored. Multiple JUnit files are merged into one summary, so a multi-report setup still produces a single result record.

#Output

Human output starts with a totals line, then lists the failing cases (failures and errors). Each failure line shows its location, kind, fully qualified name, and the first line of the failure message:

results format=junit files=1 suites=18 tests=412 failures=2 errors=0 skipped=4 time=42.318s
failed:
  src/auth.test.ts        failure  auth.login → returns user — expected 200, got 401
  src/sync.test.ts        failure  sync.rsync → handles deletes — timed out after 30s

--failed-only drops the totals line and prints just the failing cases. When no failures are recorded it prints no failed test cases recorded. If the run has no results at all, plain output is no test results recorded for <run-id>.

--json prints the stored summary. The failed array carries each failing case; file entries are plain paths.

{
  "format": "junit",
  "files": ["junit.xml", "reports/junit.xml"],
  "suites": 18,
  "tests": 412,
  "failures": 2,
  "errors": 0,
  "skipped": 4,
  "timeSeconds": 42.318,
  "failed": [
    {
      "suite": "src/auth.test.ts",
      "name": "login → returns user",
      "classname": "auth",
      "file": "src/auth.test.ts",
      "message": "expected 200, got 401",
      "type": "AssertionError",
      "kind": "failure"
    }
  ]
}

With --json --failed-only, only the failed array is printed (an empty array when there are no failures or no results).

#Storage limits

The coordinator keeps result records small enough for the run and lease detail pages to render quickly:

aggregate counters (suites, tests, failures, errors, skipped, time) are kept

verbatim;

the failed-case list is bounded;
long strings (test, suite, and message text) are truncated;
the file list keeps paths only, never raw bytes.

#results vs logs

results is the structured summary: which suite passed and which cases

failed.

logs is the retained command output: what the command actually printed.

Use results for dashboards and quick triage. Use logs when you need the full stack trace.

#Flags

--id <run-id>     run id (also accepted as the first positional argument)
--failed-only     print only failed test cases
--json            print JSON

#Supported formats

Today only JUnit XML is parsed. Other formats and cross-run flaky-test correlation are tracked in Test results.