Artifact Registry and Cloud Build

A typical pipeline on Google Cloud: Cloud Build builds and tests, Artifact Registry stores the image, and Cloud Deploy or a deploy step releases it to Cloud Run or GKE.

flowchart LR
  GH["GitHub push to main"] --> TR["Cloud Build trigger"]
  TR --> CB["Build steps<br/>test, docker build, push"]
  CB --> AR["Artifact Registry<br/>asia-southeast1-docker.pkg.dev"]
  AR --> SCAN["Vulnerability scanning"]
  CB --> DEP["Deploy to Cloud Run / GKE"]
  %% step GH: A push to main (or a pull request) starts the pipeline.
  %% step TR: A Cloud Build trigger connected to the repository runs cloudbuild.yaml as a dedicated service account.
  %% step CB: Each step runs in its own container: run tests, build the image, push it.
  %% step AR: The image is stored in a regional Docker repository with IAM-controlled access.
  %% step SCAN: Artifact Analysis scans images for known vulnerabilities in OS packages and language dependencies.
  %% step DEP: A final step (or Cloud Deploy) rolls the new image out to Cloud Run or GKE.

Artifact Registry

• Repositories per format: Docker, Maven, npm, Python, Go, apt, yum, generic.
• Regional or multi-regional; image path: LOCATION-docker.pkg.dev/PROJECT/REPOSITORY/IMAGE:TAG.
• IAM roles: roles/artifactregistry.reader (pull), writer (push), repoAdmin.
• Remote repositories cache Docker Hub or PyPI; virtual repositories combine several behind one URL.
• Cleanup policies delete old untagged images automatically.
• Container Registry (gcr.io) is retired: use Artifact Registry.

Cloud Build

# cloudbuild.yaml
steps:
- name: python:3.12
  entrypoint: bash
  args: ["-c", "pip install -r requirements.txt && pytest"]
- name: gcr.io/cloud-builders/docker
  args: ["build", "-t", "asia-southeast1-docker.pkg.dev/dl-lab-dev/shop/web:$SHORT_SHA", "."]
images: ["asia-southeast1-docker.pkg.dev/dl-lab-dev/shop/web:$SHORT_SHA"]
options:
  logging: CLOUD_LOGGING_ONLY

• Triggers run on push, pull request, tag, Pub/Sub message or manually.
• Run builds as a user-specified service account with only the roles it needs.
• Private pools run builds inside your VPC for private resources.
• Use Secret Manager in availableSecrets instead of plain variables.
• Binary Authorization can require that only signed or scanned images deploy to GKE/Cloud Run.

Cloud Deploy

A managed delivery pipeline: dev → staging → prod targets, promotions, approvals, canary releases and rollbacks for GKE and Cloud Run.

gcloud artifacts repositories create shop --repository-format=docker --location=asia-southeast1
gcloud auth configure-docker asia-southeast1-docker.pkg.dev
gcloud builds submit --tag=asia-southeast1-docker.pkg.dev/dl-lab-dev/shop/web:1.4.0

Traps: the old default Cloud Build service account had broad Editor-like rights, so set your own; pushing needs writer on the repository, not project Viewer; latest tags make rollbacks and audits hard, use commit SHAs.