Skip to main content
blob revisions lists every revision a blob has, newest first, marks the latest, and shows each one’s phase and status. It is what turns a REVISION_NOT_WRITABLE failure into something self-diagnosing: the command that refused you named a phase, and this is where you see which revisions are in which.

​
Synopsis

The command has no flags of its own. --org and --json are global, so they go before the subcommand.

​
What it does

  1. Parses the reference, exactly as blob show does.
  2. Fetches the blob record. Required, not enrichment: the listing itself does not report which revision is the latest, so the * marker comes from the record’s latest_revision_id.
  3. Lists the revisions.
  4. Reads the blob’s limits to decide whether the listing may have truncated. That read needs an admin key, so it usually fails; it degrades silently and the check is simply skipped.
  5. Sorts newest first by created_at and prints one row per revision. The platform returns index order, which is neither documented nor useful, and the reason to run this command is almost always to find a recent revision.
An empty listing prints nothing at all — not even the header — and exits 0. A bare column header over no rows is noise a pipeline has to filter back out. Under --json the payload carries blob and revisions, each entry holding id, phase, status, created_at, comment, parent_id and the boolean latest. parent_id is in the JSON only; the rendered table leaves it out.

​
Phases, and which of them a command will accept

Both columns additionally require the revision’s status to be ready, which is what the STATUS column is for. This table is why the command exists in the shape it does. The platform’s own rejection for an unusable phase is a 400 bad request whose message does not mention the revision at all, so the CLI pre-checks the phase before it writes anything and reports REVISION_NOT_WRITABLE locally, naming the phase it found. When you get that code, this listing is the answer to “then which revision can I write to?” — the phase column is right there, and * marks the one a manifest’s revision: latest resolves to.

​
The truncation advisory

REVISION_LIST_TRUNCATED is raised when the number of revisions returned has reached the blob’s configured revisions_per_blob maximum. The platform cannot page this listing, so a blob at its cap may be missing revisions that were silently dropped — nothing in the API reports it, which is why the CLI infers it from the count. The check runs only when the limit is readable, which needs an admin-scoped key. With the read or write keys the platform recommends for automation, the limit read fails, the check is skipped, and the command stays silent rather than guessing. See blobhub blob limits for why that is, and for what else it explains. Like every advisory, it goes to stderr, is suppressed by --quiet and whenever stderr is not a TTY, and never changes the exit code.

​
Errors

The revisions route is gated on read, not admin — and that was confirmed against the deployed API with a non-admin key, not merely read off the handler. It matters: if it needed admin, this command would be useless to exactly the keys the platform tells automation to use, and the one command that explains a phase failure would be unavailable to the automation hitting it.

​
See also