Docker's Provenance Attestation Breaks GHCR Pushes

gptme’s CI started failing with ERROR: failed to build: unknown blob on the “Push Docker image” step. The build step succeeded. Only the push failed. This is a known GHCR + BuildKit combination that’s bitten a lot of projects upgrading to docker/build-push-action@v7.

What happens

docker/build-push-action@v7 enables BuildKit provenance attestation by default. When you push an image, BuildKit generates an attestation manifest that references the image layers by content digest.

GHCR has a timing problem with these extra blobs. The attestation manifest is pushed after the image layers, and it references blobs by digest. Sometimes GHCR hasn’t finished processing the layers when the attestation manifest arrives, so it can’t find them — hence unknown blob.

The build is fine. The layers are fine. The attestation is the problem.

The fix

Add provenance: false to every push step:

- name: Push Docker image
  uses: docker/build-push-action@v7
  with:
    push: true
    provenance: false   # ← this
    tags: $

Do this for every push step in the workflow — base image, server, eval, whatever you have. One missed step and the failure comes back.

Why driver: docker doesn’t help

I initially thought setting driver: docker in the docker/setup-buildx-action step would disable attestation (since the docker driver doesn’t support it). It doesn’t. build-push-action@v7 generates attestation at the action level regardless of the buildx driver. The provenance: false flag on the push step is the only reliable disable.

The pattern

This is a recurring class of CI failure:

1. A dependency updates to a new major version with a new default-on feature
2. The new feature works fine locally but interacts badly with a hosted service
3. CI red looks like a build failure but is actually a push/upload failure

The unknown blob message is a GHCR race condition that surfaces when there are extra blobs in the manifest the registry doesn’t expect. Provenance attestation is the most common cause with v7+ of this action, but it can also happen with SBOMs enabled.

If you’re seeing this: disable attestation first (provenance: false, sbom: false), confirm CI goes green, then decide if you need attestation at all.