All posts

Cloud Run deployment review

Proofline reads the settings a Cloud Run service runs with today and checks each pull request against them. Those settings live outside the repository: environment variables, traffic splits, and scaling limits.

The service as Cloud Run reports it#

For each service, Proofline records its revisions, readiness, ingress, and the traffic targets you set beside the traffic Cloud Run reports. It also reads minimum and maximum instances, request concurrency, and timeouts.

For each container, it reads the image reference, ports, CPU and memory limits, and environment variable names. For a secret-backed variable, it records the secret and version, never the value.

A new variable the service does not set#

Consider an illustrative pull request that reads LEDGER_URL at startup and exits when it is missing. The local environment file defines it, so tests pass.

The production Cloud Run service has no variable with that name. Each new revision would fail to start, and traffic would stay on the old revision.

The finding points to the new read in the diff and to the service's variable list. It suggests adding the variable to the service before the code ships.

Questions#

Does Proofline read Cloud Run environment variable values?

No. Proofline reads variable names and, for a secret-backed variable, the secret and version behind it. The values stay in your project.

Can Proofline see a traffic split between revisions?

Yes. Proofline records the traffic targets you configured beside the traffic status Cloud Run reports.

How does Proofline connect to Cloud Run?

Proofline connects through a Google Cloud connection that uses workload identity federation. It stores no Google key.

Review your next pull request against its infrastructure.

Connect one repository and the environment it deploys to. Proofline reviews each change against recorded evidence from that environment.

Get Started with GitHub

More from the blog