Support artifacts list/download filter by path/state

[lizrabuya]

Description

Adds --path and --state filters to bk artifacts list and bk artifacts download,
so users can drill into a build's artifacts by glob or state instead of downloading
everything or looking up an ID first. Uses the new Path / State fields on
ArtifactListOptions in go-buildkite v5.10.0.

Changes

• Bump go-buildkite to v5.10.0 to pick up Path / State on ArtifactListOptions.
• Wire --path and --state through to the Buildkite API on both list and download.
• Reject --path / --state combined with a positional artifact ID. The check runs
  before build resolution (no wasted API calls) and the error carries a suggestion
  pointing users at the correct usage.
• Normalise state casing (--state Finished → finished) before it hits the API.
• Help text on both commands documents the glob syntax with a concrete
  log/rspec*.json example; identical wording across both files.
• Empty-result messaging now reflects the active filters, e.g.
  No artifacts found matching path 'coverage/**' and state 'finished'. — via a
  shared writeNoArtifactsMessage helper reused by both commands.
• Add unit tests for cmd/artifacts/list.go and cmd/artifacts/download.go
  covering the new filter plumbing, pagination, validation, filter-aware
  empty-result messaging, and table rendering.

Examples

$ bk artifacts list 429 --path "log/rspec*.json"
$ bk artifacts list 429 --state finished
$ bk artifacts download --build 429 --path "log/rspec*.json"
$ bk artifacts download --build 429 --state finished

Testing

• Tests have run locally (with go test ./...)
• Code is formatted (with go fmt ./...)

Disclosures / Credits

Claude Code assisted with help-text/error-message polish, extracting the shared writeNoArtifactsMessage helper, and drafting the unit tests under cmd/artifacts. I reviewed and directed each change before committing.

[buildsworth-bk-app]

I didn't find a concrete issue in the filter plumbing, pagination, or command validation. This adds new artifact-selection behavior to both list and download, so it would still benefit from a human sanity-check.

Want to dig deeper?

Paste this into your agent to explore the findings from this review's Buildkite build:

Download the buildsworth logs from build 11631, then answer my questions about the findings.

Install the reading-buildsworth-logs skill to run this.

About buildsworth

Model: gpt-5.6-sol with xhigh thinking.

How to request a review: Comment @buildsworth-bk review on the PR, or request buildsworth-bk as a reviewer.

Risk labels (how buildsworth classifies risk) — buildsworth classifies risk itself from the diff. To let it approve, grant L2 approval by mentioning @buildsworth-bk (see L2 approval grant):

• L1 — Low risk (dep bumps, docs/copy, lockfiles, small presentational fixes). buildsworth may approve by default.
• L2 — Standard risk (new UI, additive API fields, refactors). Approved only with an L2 grant; otherwise comment-only.
• L3 — High risk (auth, migrations, payments, secrets, perf-critical paths). Human review always required.