Architectural Considerations When Designing Cloud Build Pipelines to Deploy Cloud Run

📅 Created: 2022/06/15, Updated: 2025/07/06 ⏱️ Estimated reading time ~1 min (220 words)

A summary of best practices for constructing continuous deployment pipelines from Cloud Build to Google Cloud Run, covering substitution variables, image caching, and Artifact Registry lifecycle pruning.

Table of Contents

Example Cloud Build Pipeline
① Defining Environment-Specific Substitutions
② Building & Pushing Container Images
③ Deploying to Cloud Run
④ Managing Artifact Registry Image Lifecycles

Example Cloud Build Pipeline

# ① Define environment-specific variable substitutions
substitutions:
  _CPU: "1"
  _MEMORY: "256Mi"
  _MAX_INSTANCES: "1"
  _MIN_INSTANCES: "1"
  _REGION: "asia-northeast1"

steps:
# ② Build and push container image to Artifact Registry
- name: "gcr.io/cloud-builders/docker"
  args: ["build", "-t", "${_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPO_NAME}/prod:${COMMIT_SHA}", "."]

- name: "gcr.io/cloud-builders/docker"
  args: ["push", "${_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPO_NAME}/prod:${COMMIT_SHA}"]

# ③ Deploy container to Cloud Run
- name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
  entrypoint: bash
  args:
    - -c
    - |
      gcloud run deploy \
      ${REPO_NAME} \
      --image ${_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPO_NAME}/prod:${COMMIT_SHA} \
      --cpu=${_CPU} \
      --memory=${_MEMORY} \
      --max-instances=${_MAX_INSTANCES} \
      --min-instances=${_MIN_INSTANCES} \
      --region ${_REGION}

# ④ Artifact lifecycle & cleanup of older image digests
- name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
  entrypoint: bash
  args:
    - -c
    - |
      apt -y install jq
      five_minutes_ago=$(date -d '5 minutes ago' +%Y-%m-%dT%H:%M:%S)
      for image in `jq -c ".[]"<<<$(gcloud artifacts docker images list ${_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPO_NAME} --format json --filter "updateTime<${five_minutes_ago}")`; do
        gcloud artifacts \
        docker \
        images \
        delete \
        ${_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPO_NAME}/prod@$(jq -r ".version"<<<$image;) \
        --delete-tags \
        --quiet
      done

① Defining Environment-Specific Substitutions

By parameterizing instance resource specifications ( _CPU , _MEMORY ), scaling bounds ( _MIN_INSTANCES , _MAX_INSTANCES ), and deployment targets ( _REGION ) in substitutions , configuration logic remains clean and centralized.
This is far more readable and maintainable than embedding arbitrary hardcoded parameters directly inside inline deploy commands.
If separating parameter configuration files across distinct environments (staging vs. production) is required, consider decoupling them via external substitution YAML files.

② Building & Pushing Container Images

Builds the container image tagged with ${COMMIT_SHA} and securely pushes it to Google Cloud Artifact Registry.
To accelerate build execution times on CI, consider introducing layer caching via --cache-from pointing to the previous image tag.
- Note: Pulling previous image layers incurs small egress/storage costs; for small, lightweight base images like alpine/nginx, builds without cache may already be fast enough.

③ Deploying to Cloud Run

Invokes gcloud run deploy with the designated image, resource limits, and target region. Cloud Run manages blue/green zero-downtime traffic switching automatically.

④ Managing Artifact Registry Image Lifecycles

Since Artifact Registry repositories can accumulate unbounded historical container layers, maintaining a regular automated pruning policy is essential to avoid unnecessary storage costs.
The script snippet demonstrates querying images older than a given timestamp via gcloud artifacts docker images list and safely deleting expired image tags and manifests.
Customize the retention policy (e.g., preserving the latest N revisions or filtering by semantic release tags) to meet your team’s operational rollback requirements.