#8: run logs has no --job filter, so triaging one red job means grepping all six · rickub/cli

Evidence

rickub run logs <n> prints the whole run's interleaved output. There is no way
to ask for one job:

$ rickub run logs --help
      --host string    API host
      --json           output raw JSON instead of a table
  -R, --repo string    target repo
      --token string   personal access token

A rickub CI run has six jobs (engine, registry, web, ssh, lint,
coverage), and when one goes red the other five are noise. Today the only way
to see why ssh failed is to dump everything and grep — and the interesting
lines are things like ##[error]getaddrinfo EAI_AGAIN golang.org, which appear
in a stream that also contains full Rust and Go build output.

Impact

This is a direct multiplier on the cost of every misdiagnosis under #367 (the
guest-DNS flake that reddens ~13% of runs for reasons the author cannot act on).
Each triage means pulling a multi-megabyte log to read ~5 lines. During a deep
queue — 30 runs backed up behind ~4 slots — that triage happens repeatedly, and
the cost of not triaging is worse: it trains reviewers to blind-re-run red MRs,
which is how a real failure eventually gets waved through.

The information is already there. rickub run view <n> knows the per-job and
per-step breakdown, so the log stream is evidently attributable to a job.

Acceptance criterion

rickub run logs <n> --job <name> prints only that job's lines; an unknown job
name errors listing the valid ones rather than silently printing everything (a
typo that returns the full log is worse than no flag, because it looks like it
worked). --job composes with --json.

Nice-to-have in the same change: --failed, meaning "every job whose conclusion
is not success", since that is the actual question being asked ~90% of the time.

run logs has no --job filter, so triaging one red job means grepping all six #8

Evidence

Impact

Acceptance criterion