Is your feature request related to a problem?
There is no way to read build or job annotations from the CLI. bk --help on 3.55.0 lists no
annotation subcommand, and no existing command surfaces them.
Annotations are where most pipelines put the human-readable version of a failure — the test
summary table, the lint diff, the "here is what broke and where" block that a buildkite-agent annotate call emits precisely so a person does not have to read the raw log. Losing that in
the CLI means falling back to the full job log for information the pipeline already
summarised.
The REST API exposes them (GET /organizations/{org}/pipelines/{pipeline}/builds/{number}/annotations),
and the official MCP server exposes list_annotations, so this is a CLI surface gap rather
than a missing capability.
Describe the solution you'd like.
bk annotation list <build-number> -p <pipeline>, following the conventions the other list
commands already use — JSON by default, --no-pager, and honouring the same -p resolution.
Two things that would make it substantially more useful for the agent-oriented direction the
CLI is already heading in:
- Filter by style:
--style error,warning — an agent triaging a failure wants the error
annotations, not the informational ones.
- Participate in
--agent / --max-tokens the way bk job log now does, since annotation
bodies can be large.
Describe alternatives you've considered.
bk api can reach the endpoint directly, but that gives up the org/pipeline resolution,
output formatting, and token budgeting that the rest of the CLI provides, and it means
hand-constructing the path. It works as a workaround, not as the answer.
Additional context
Version bk 3.55.0.
Is your feature request related to a problem?
There is no way to read build or job annotations from the CLI.
bk --helpon 3.55.0 lists noannotation subcommand, and no existing command surfaces them.
Annotations are where most pipelines put the human-readable version of a failure — the test
summary table, the lint diff, the "here is what broke and where" block that a
buildkite-agent annotatecall emits precisely so a person does not have to read the raw log. Losing that inthe CLI means falling back to the full job log for information the pipeline already
summarised.
The REST API exposes them (
GET /organizations/{org}/pipelines/{pipeline}/builds/{number}/annotations),and the official MCP server exposes
list_annotations, so this is a CLI surface gap ratherthan a missing capability.
Describe the solution you'd like.
bk annotation list <build-number> -p <pipeline>, following the conventions the other listcommands already use — JSON by default,
--no-pager, and honouring the same-presolution.Two things that would make it substantially more useful for the agent-oriented direction the
CLI is already heading in:
--style error,warning— an agent triaging a failure wants the errorannotations, not the informational ones.
--agent/--max-tokensthe waybk job lognow does, since annotationbodies can be large.
Describe alternatives you've considered.
bk apican reach the endpoint directly, but that gives up the org/pipeline resolution,output formatting, and token budgeting that the rest of the CLI provides, and it means
hand-constructing the path. It works as a workaround, not as the answer.
Additional context
Version
bk 3.55.0.