Remember images in your cloudbuild.yaml!

If you've been using Cloud Build to automate Cloud Run service deployments for an amount of time, you might be familiar with the sort of configuration where you docker build, docker push, then gcloud run deploy your built container:

steps:
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build', '-t', 'gcr.io/myproject/myservice', '.']

  - name: 'gcr.io/cloud-builders/docker'
    args: ['push', 'gcr.io/myproject/myservice']

  - name: 'gcr.io/cloud-builders/gcloud'
    args: ['run', 'deploy', 'myservice',
           '--platform', 'managed', '--region', 'us-central1',
           '--image',  'gcr.io/myproject/myservice']

The reason you have to docker push is because you want to make sure that the container repository you're using has the most recent version of your image. If you miss the push step on your first deployment, there's nothing in the registry to deploy!

Step #1: ERROR: (gcloud.run.deploy) 
Image 'gcr.io/myproject/myservice' not found.

And if you don't push each time, the version that's deployed won't be your most recent build! (Ask me how I know.)

So if you have to have a push step, what's the point of that images field?

images ↗

The images field in the build config file specifies one or more Docker images to be pushed by Cloud Build to Container Registry.

You're already pushing the image to the Container Registry, right?

Well, that's not all this configuration does.

If you go to your service in the Cloud Run part of the Cloud Console and navigate to the Revisions tab, you'll see information about that revision of your service:

• Container image URL: the container the revision is using
• Container build: (no build information available)
• Source: (no source information available)

If you define images, even if it ends up pushing an image you've already pushed, the Container build field populates with a direct link to the Cloud Build job that built the image!

Even better, if you enable the Container Analysis API and you're running your builds based on build triggers, you get a link to the exact commit your container is based on in the Source field! (Container Analysis is free, and inspects container metadata. Not to be confused with Container Scanning, which has a cost, but also enacts vulnerability scanning)

First config, without images: config only shows Container URL.
Second config, with images: config shows a link to the Cloud Build job log.
Third config, with images and Container Analysis API: config shows additional link to the GitHub commit that triggered the build.

You can enable the Container Analysis API for your project here, or with gcloud:

gcloud services enable containeranalysis.googleapis.com

You can add images: to your cloudbuild.yaml by appending it to the end:

--- a/cloudbuild.yaml
+++ b/cloudbuild.yaml
@@ -11,6 +11,9 @@ steps:
            '--image', 'gcr.io/myproject/myservice']

+images:
+    - 'gcr.io/myproject/myservice'
+

Here's to a richer Cloud Run experience!

Learn more:

• Structure of a build config file - Cloud Build Docs
• Continuous Deployment from git using Cloud Build - Cloud Run Docs
• Creating and managing build triggers - Cloud Build Docs
• Providing metadata for images - Container Registry Docs