Gcloud Builds Tag Deploy False Success

gcloud builds submit --tag false-success trap

Problem

A common Cloud Run deploy recipe looks like this:

gcloud builds submit --tag us-central1-docker.pkg.dev/PROJECT/REPO/IMAGE:latest
gcloud run services update SERVICE \
  --image us-central1-docker.pkg.dev/PROJECT/REPO/IMAGE:latest \
  --region us-central1 --project PROJECT

When the first command fails (most commonly because the current working directory doesn't contain a Dockerfile), its single-line error scrolls off-screen above the second command's verbose progress spinner. The second command then pulls the existing :latest image from Artifact Registry — which is the previous build — and deploys it. You get:

✓ Deploying... Done.
  ✓ Creating Revision...
  ✓ Routing traffic...
Service [...] revision [...] has been deployed and is serving 100 percent of traffic.

A green "SUCCESS" deploy that did not change the running code. The user then spends hours debugging why the fix isn't live, or worse, concludes the fix doesn't work and reverts good code.

Context / Trigger Conditions

• User reports "I deployed the fix but production behavior is unchanged"
• Recent shell output contains both:
  • ERROR: (gcloud.builds.submit) Invalid value for [source]: Dockerfile required when specifying --tag
  • revision [...] has been deployed and is serving 100 percent of traffic
• The gcloud builds submit --tag … was run without a source positional argument AND the working directory does not contain the Dockerfile (common in monorepos where the Dockerfile lives under a subdirectory like cloud-run-upload/, services/api/, etc.)
• The deploy targets use the mutable :latest tag (or another tag that already exists in the registry)

Root cause

gcloud builds submit --tag IMAGE_TAG needs a source directory. When you omit it, it defaults to the current working directory, and if there's no Dockerfile there (or a cloudbuild.yaml), it exits immediately with exit code 1 — without uploading anything, without creating a build job, without touching Artifact Registry.

Because gcloud run services update --image :latest resolves :latest at deploy time from Artifact Registry, it happily redeploys whatever was there from the previous successful build. Cloud Run's response does not compare the resolved digest to what's already running; it cheerfully creates a new revision pinning the same digest. Output reads "Done" because, from Cloud Run's perspective, everything worked.

Two mistakes compound here:

1. The build failure is a single red line among otherwise-green output and it's easy to miss.
2. The :latest tag hides the fact that "the image didn't actually change" — an immutable tag (git SHA, timestamp) would have made the staleness obvious.

Solution

Immediate fix

Rerun the build from the directory containing the Dockerfile, or pass the source as a positional argument:

# Option A: cd into the directory
cd cloud-run-upload
gcloud builds submit --tag us-central1-docker.pkg.dev/PROJECT/REPO/IMAGE:latest

# Option B: pass source as positional
gcloud builds submit cloud-run-upload \
  --tag us-central1-docker.pkg.dev/PROJECT/REPO/IMAGE:latest

Wait for STATUS: SUCCESS in the output (not just for the prompt to return). Then rerun the gcloud run services update command to pull the new digest.

Permanent prevention (recommended)

1. Use immutable tags. Never deploy :latest to Cloud Run for anything that matters. Tag with git SHA or timestamp so staleness is visible:

   TAG=$(git rev-parse --short HEAD)
   gcloud builds submit cloud-run-upload \
     --tag us-central1-docker.pkg.dev/PROJECT/REPO/IMAGE:${TAG}
   gcloud run services update SERVICE \
     --image us-central1-docker.pkg.dev/PROJECT/REPO/IMAGE:${TAG} ...

   If step 1 silently fails, step 2 fails loudly with "image not found" because that tag doesn't exist yet. False-positive converted into a real error.

2. Chain with && or put the commands in a script with set -e. Copy-pasting two separate commands lets the second run even if the first errored:

   #!/bin/bash
   set -euo pipefail
   cd "$(dirname "$0")/cloud-run-upload"
   TAG=$(git rev-parse --short HEAD)
   IMAGE=us-central1-docker.pkg.dev/PROJECT/REPO/IMAGE:${TAG}
   gcloud builds submit --tag "${IMAGE}"
   gcloud run services update SERVICE --image "${IMAGE}" --region us-central1

3. Verify the build output contains STATUS: SUCCESS before running the deploy. The last line of a successful gcloud builds submit is STATUS: SUCCESS. If the last line is anything else (especially ERROR:), the build did not happen.