[DEP-4265] Add depot ci metrics

[121watts]

Summary

depot ci metrics gives humans and scripts the metrics view the app already had.

What was happening

The CLI could inspect CI status and logs, but it had no command for CPU and memory metrics. Customers writing scripts or agents had no clean way to ask for attempt samples or job/run metric summaries.

What happens now

• Adds depot ci metrics <attempt-id> plus explicit --attempt, --job, and --run selectors.
• Adds --output text|json, with deterministic snake_case JSON for automation.
• Prints exact attempt drill-down commands in job/run human output.
• Maps availability codes to readable JSON strings like available, no_sandbox, no_time_range, and no_samples.
• Updates the generated CI protobuf/connect client for the new metrics RPCs.

Anything else?

This is the CLI half of DEP-4265 and depends on the API draft: https://github.com/depot/api/pull/3638

---

Note

Medium Risk
Adds new CLI surface area and new CI RPC wrappers for metrics retrieval; main risk is output/flag behavior changes and handling of large metric responses via new error paths.

Overview
Adds depot ci metrics to fetch CI CPU/memory metrics at the attempt, job, or run level (positional attempt ID or mutually-exclusive --attempt|--job|--run), with --output text|json and deterministic snake_case JSON payloads.

Extends the CI API client wrappers with CIGetJobAttemptMetrics, CIGetJobMetrics, and CIGetRunMetrics, and adds targeted error handling for ResourceExhausted (actionable “narrow your request” guidance) and NotFound (suggests using job/run selectors).

^{Reviewed by Cursor Bugbot for commit d124c87. Bugbot is set up for automated code reviews on this repo. Configure here.}

[linear-code]

DEP-4265 M5: Expose CI metrics parity

[ischolten]

will workflowid as a filter come later?

[121watts]

Yes, workflow filtering is a later pass. This CLI change mirrors the current public run/job/attempt metrics RPCs and keeps workflow selection out of this already-large PR. -watts[bot]

[ischolten]

metricStatsJSON handles scalar fields with nil-safe getters, but then reads optional pointer fields directly from stats. Since this proto message field is nullable on the Go client, an omitted stats message would panic here instead of emitting an empty stats block. Can we guard stats == nil or normalize it to an empty CIMetricsStats before reading the optional fields?

[121watts]

Yep, fixed in 4f9d544. metricStatsJSON now returns an empty stats object when the message is omitted, so the optional pointer fields are never read through nil. -watts[bot]

[ischolten]

Same nil-stats issue on the text path: the code calls nil-safe getters first, but then directly checks stats.PeakCpuUtilization / stats.AverageCpuUtilization. A response with stats omitted will panic while rendering human output. A small helper that returns empty stats for nil would cover both JSON and text formatting.

[121watts]

Fixed in 4f9d544 as well. The text renderer now normalizes missing stats to an empty CIMetricsStats before reading optional CPU or memory pointers. -watts[bot]

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is ON. A cloud agent has been kicked off to fix the reported issue. You can view the agent here.}

^{Reviewed by Cursor Bugbot for commit 4f9d544. Configure here.}

[cursor]

New "metrics" command missing from registration guard test

Low Severity

The new metrics subcommand is registered in NewCmdCI but not added to the wanted slice in TestCICommandRegistration in ci_test.go. That test's comment explicitly says "New verbs should be added to the wanted slice below." Without the entry, a future refactor that accidentally drops cmd.AddCommand(NewCmdMetrics()) won't be caught by the guard test.

 

^{Reviewed by Cursor Bugbot for commit 4f9d544. Configure here.}