CI/CD and deployments

This page describes how code moves from commit to Cloud Run.

GitHub Actions (CI)

Workflows live under .github/workflows/ and run on PRs or main pushes.

• pr-title-lint.yml: enforces type(scope): description title format.
• ruff.yml: formatting and lint checks on Python changes.
• pytest.yml: runs uv sync --all-packages --frozen and uv run pytest.
• publish_desktop_updates.yml: uploads Raven release assets to GCS on GitHub release publication.

Cloud Build (build + release)

Build configs live under ci/cloudbuild/ and are referenced by Terraform triggers in infra/envs/*/cloud_build.tf.

Typical steps inside a service build config:

1. Build Docker image with BuildKit.
2. Push image to Artifact Registry.
3. Create a Cloud Deploy release using the service or job skaffold.yaml.

Cloud Deploy (delivery)

Cloud Deploy pipelines and targets are defined in infra/envs/*/cloud_deploy.tf. There is a pipeline per component (service or job) that deploys to a target with the same name. Deploy parameters inject environment-specific values into manifests.

Skaffold and manifests

Each component owns its deployment definitions:

• Services: services/<name>/deploy/service.yaml + services/<name>/deploy/skaffold.yaml.
• Jobs: jobs/<name>/deploy/job.yaml + jobs/<name>/deploy/skaffold.yaml.

Skaffold renders the raw YAML and Cloud Deploy applies it to Cloud Run. service.yaml and job.yaml files may include from-param placeholders that are filled by Cloud Deploy parameters.

Service and job definitions

• Cloud Run services define ingress, concurrency, and env vars in services/*/deploy/service.yaml.
• Cloud Run jobs define run specs in jobs/*/deploy/job.yaml.

Keep these manifests in sync with runtime settings in each service.