Google Cloud Build镜像已推送打标仍报‘No such image’问题求助

The Problem Context #

You've set up a two-step GCB pipeline where:

1. First, you build a Docker image via build_image.sh, tag it locally as base-image:latest, and push it to a remote repo
2. Second, you run tests using that local tag to skip pulling the image again, saving time and bandwidth

Your configs look like this:

cloudbuild.yaml #

steps:
- name: 'gcr.io/cloud-builders/docker'
  entrypoint: bash
  args: ['./build_image.sh','$PROJECT_ID','base-image']
- name: 'base-image:latest' # Avoid pulling the image again
  args: ['-f', './verify_image.ps1']

build_image.sh #

#!/bin/bash
project=$1
applicationName=$2
version=1.0.3
image="gcr.io/$project/$applicationName:$version"
local_image="$applicationName:latest"
docker build -t $image .
echo "Tag image to make it locally availiable so we dont have to do a new pull"
docker tag $image $local_image
docker push $image
# docker run $local_image # Runs fine locally

The Issue #

Most of the time this works, but occasionally step 2 fails with:

Step #2: Already have image (with digest): base-image:latest
Finished Step #2
ERROR
ERROR: build step 2 "base-image:latest" failed: starting container: Error response from daemon: No such image: base-image@sha256:XXXX

It's intermittent (0-5 failures out of 10 builds for the same commit), and you've already tried verifying tags/digests, testing local runs, and switching to official/latest Docker builders without luck. You suspect a race condition with the shared Docker daemon in GCB.

Solutions That Work #

1. Use Exact Remote Image Reference + Digest in Step 2 #

GCB's step image resolution might prioritize fetching the remote digest over using the local tag, causing the race. Instead, pass the exact image reference from step 1 to step 2:

Update build_image.sh

After pushing the image, write the full image reference to a file (or use GCB's builder output env var):

# Add this after docker push
echo "gcr.io/$project/$applicationName:$version" > /workspace/image_ref.txt
# Alternatively, capture the digest for even more precision:
# image_digest=$(docker inspect --format='{{index .RepoDigests 0}}' $image)
# echo "IMAGE_DIGEST=$image_digest" >> $BUILDER_OUTPUT

Update cloudbuild.yaml

Reference the exact image from the file in step 2:

steps:
- name: 'gcr.io/cloud-builders/docker'
  entrypoint: bash
  args: ['./build_image.sh','$PROJECT_ID','base-image']
- name: '$(cat /workspace/image_ref.txt)'
  args: ['-f', './verify_image.ps1']

This bypasses any local tag ambiguity by using the precise remote image you just built.

2. Explicitly Run the Local Image via Docker Builder #

Instead of letting GCB resolve the image for the step, use the Docker builder to run the local tag directly. This skips GCB's image resolution logic entirely:

steps:
- name: 'gcr.io/cloud-builders/docker'
  entrypoint: bash
  args: ['./build_image.sh','$PROJECT_ID','base-image']
- name: 'gcr.io/cloud-builders/docker'
  args: ['run', '--rm', 'base-image:latest', '-f', './verify_image.ps1']

This way, you're directly telling the Docker daemon to use the local tag you created, avoiding any race with GCB's metadata checks.

3. Temporary Workaround: Add a Short Delay #

If you need a quick fix while implementing the above, add a sleep step between build and test to give Docker daemon time to sync metadata:

steps:
- name: 'gcr.io/cloud-builders/docker'
  entrypoint: bash
  args: ['./build_image.sh','$PROJECT_ID','base-image']
- name: 'gcr.io/cloud-builders/bash'
  args: ['sleep', '5'] # Adjust time based on your build's typical latency
- name: 'base-image:latest'
  args: ['-f', './verify_image.ps1']

Note: This is a band-aid, not a permanent fix—sleep times can vary based on GCB's infrastructure, so you might still hit the race condition occasionally.

Why This Happens #

GCB resolves step images by checking remote repos for digests, even if you specify a local tag. When step 2 starts before the Docker daemon finishes updating metadata for the new local tag, GCB thinks it has the image (from the remote digest) but the daemon can't find the local image matching that digest yet. This creates the confusing "already have image but can't find it" error.

内容的提问来源于stack exchange，提问作者Christian Mikkelsen