sincecutoff.com
← all changes

bk build retry-failed-jobs queues retries for failed jobs

Introduced 2026-10-20 · score 0.97

HOW TO USE IT

When failed jobs in an existing build are safe to rerun, run `bk build retry-failed-jobs` with the build number, `org/pipeline/number`, or build URL; use `--pipeline` if inference is ambiguous. Retries queue asynchronously; follow progress with `bk build view` or `bk build watch`.

bk build retry-failed-jobs 123 --pipeline my-pipeline
bk build retry-failed-jobs acme/my-pipeline/123 --states failed,soft_failed --yes --json
bk build retry-failed-jobs https://buildkite.com/acme/my-pipeline/builds/123 --yes --no-input --text

WHY THIS HELPS

Retry retryable failed jobs in an existing Buildkite build after deciding they are safe to rerun.

REQUIREMENTS AND LIMITATIONS

  • Version: v3.64.2
  • <build-number> (required): Build number, org/pipeline/number, or Buildkite build URL.
  • --pipeline: Pipeline slug or org/pipeline; inferred from configuration or repository if omitted.
  • --states: Comma-separated failure states: canceled, expired, failed, soft_failed, timed_out. Omitted or empty retries all retryable failed jobs.
  • --yes: Skips required confirmation.
  • --no-input: Without --yes, fails without retrying.
  • --json: Output as JSON; JSON/YAML never prompts for pipeline selection.
  • --text: Output as text.
  • --yaml: Output as YAML; JSON/YAML never prompts for pipeline selection.
  • Prerequisite: Requires a token with the write_builds scope.
  • Prerequisite: Confirmation is required unless --yes is supplied; --no-input without --yes fails without retrying.
  • Requires the `write_builds` token scope.
  • Confirmation is required unless `--yes` is supplied; `--no-input` without `--yes` fails without retrying.
  • Malformed selectors and conflicting explicit build/pipeline targets are rejected.
  • By default, including `--states ''`, all retryable failed jobs are retried. `--states` accepts `canceled`, `expired`, `failed`, `soft_failed`, and `timed_out`.
  • The operation is not limited to infrastructure failures and does not check whether jobs are safe to rerun; retries can repeat side effects, including deployments.
  • The API returns `202 Accepted` and asynchronously queues retries; the count reports jobs queued, not completed or successful retries.
  • If the request is accepted but its count cannot be read, the command fails without a receipt and warns to check the build before resubmitting.
  • JSON/YAML never prompts for pipeline selection; specify `--pipeline` when inference is ambiguous.

FIRST-PARTY EVIDENCE

Check the installed version and the source before using it. Entry JSON

Report a problem with this card