How Can You Verify the Right Release Is Running on Google Cloud Run?

A release is a sequence of independently observable states. The commit describes the source you intended to ship. The build produces an artifact. The digest identifies that artifact. The revision combines container images with runtime configuration. Traffic settings choose which revision handles service requests. Public verification checks the resulting experience.

Keep these identifiers together in a release record. The matrix below is a recommended operational record, not the field list of IHP's public release endpoint. Each row answers a different question; retaining one identifier cannot replace the others.

IHP's deployment script requires the main branch, a clean working tree and a local commit matching the refreshed remote main branch. These checks prevent an ordinary release from silently including uncommitted work or an outdated checkout. The script also checks access to the intended cloud project and inspects the files that would enter the Cloud Build upload context.

The upload inspection rejects common secret-bearing filenames before submitting the build. This matters because a repository can be clean while ignored local configuration still exists beside it. Build-context controls and source-control controls address different boundaries. Neither filename filtering nor a clean checkout replaces careful secret handling.

The local build installs dependencies from the lockfile, checks generated sitemap consistency and verifies that release metadata contains the intended full commit SHA. It then checks that building did not change tracked files. This creates a more controlled starting point, but does not establish a hermetic or bit-for-bit reproducible build: base images, build tools and external inputs still require explicit management.

Run the project's required quality checks as their own release gate. IHP's quality workflow and production deployment are separate operations; a merged change does not automatically mean that the website has been deployed.

A tag is a readable reference; a digest identifies a specific container artifact. IHP names the release image with the commit SHA, refuses to reuse an existing release tag, resolves the resulting digest after Cloud Build, and passes the digest reference to Cloud Run. The release therefore records an explicit artifact selection before deployment.

Google Cloud Run can also accept an image tag directly. Its deployment documentation states that the tag is resolved to a digest and the resulting revision keeps serving that digest. Retagging an image does not make an existing revision start pulling different code. Cloud Run imports the image at deployment rather than pulling it anew whenever an instance starts.

The value of resolving the digest explicitly is operational clarity. You can compare the selected artifact with the revision without relying on what a tag happens to reference later. If two builds originate from the same source but produce different artifacts, recording the digest preserves that distinction.

Retain the build reference alongside the digest. A digest identifies content; the surrounding build record explains the inputs and process that produced it.

IHP creates the new revision with no production traffic allocated to it. The script then confirms that a new revision exists, checks its reported readiness status, and compares the configured container image reference with the expected digest. A mismatch stops the release before the script changes traffic.

Cloud Run defines a revision as an immutable snapshot of code and configuration. That means an image match is necessary but insufficient when the change also concerns runtime settings. Review relevant configuration such as the service identity, endpoint selection, resource limits and secret references without copying secret values into release evidence.

Readiness answers a platform question about whether the revision is ready to serve. It does not prove that a customer can complete a workflow, that a downstream API accepts the request, or that a database operation preserves the intended data. Define application checks separately.

For more extensive automation, inspect the named Ready condition and completed reconciliation rather than relying on a revision name or a deployment success message alone. Google's revision API reference exposes observed state for this purpose.

IHP's script expects one existing production revision receiving 100 percent of traffic before it starts the replacement. After the new revision passes readiness and image checks, the script assigns it 100 percent of traffic and runs the public website verifier. The order matters: readiness and artifact checks happen before promotion; the complete public smoke sequence happens afterward.

This is a direct promotion workflow. It does not currently implement a canary rollout or a full end-to-end test against the new revision before production traffic moves. Those capabilities should be described as potential extensions rather than assumed safeguards.

Cloud Run supports revision tags for direct testing and traffic allocations for gradual rollouts. A team can add a test URL for a candidate revision or move traffic in measured stages when the application's risk warrants that process. A tagged revision test still needs separate validation of the production domain and its routing.

After changing traffic, capture the observed allocation as release evidence. Keep deployment operations serialized or coordinated: a second release running simultaneously can make an unqualified reference to the latest revision ambiguous.

IHP's public verifier requests the homepage, discovery files, sitemap URLs and selected structured-data examples through the production domain. It checks response status and content type, canonical URLs, redirect behavior and release identity. These are concrete website acceptance checks: they can detect a deployment that is reachable but serves incomplete or inconsistent publishing surfaces.

The website also exposes release.json. The current metadata contains a schema version, commit SHA, environment identifiers and a commit-tagged image reference. It does not contain the resolved image digest or Cloud Run revision name. Those belong in the wider release record rather than being inferred from this response.

The verifier requires the endpoint to return JSON with a no-store cache directive and the expected metadata values. That makes it useful for detecting an unexpected public release. It remains an application-controlled assertion: it is not signed build provenance, and its presence alone cannot prove how an image was built.

Cross-check it against the selected digest, observed revision and traffic configuration. For an application with authenticated workflows, add controlled checks that establish the relevant outcome. A successful read of a version endpoint cannot establish successful account creation, payment processing or downstream record persistence.

When release evidence disagrees, avoid rebuilding immediately. First identify the earliest broken connection. A public response showing an older commit might reflect traffic allocation, domain routing or cached content; it does not by itself prove that the new container was built incorrectly.

Use a short diagnostic sequence that compares expected and observed values. Preserve the failed response and the corresponding release identifiers before making another change. That makes the next action explainable and reduces the chance of replacing evidence with a second ambiguous deployment.

IHP records the previous production revision and prints the command required to restore its traffic allocation. If public verification fails, the script reports the failure, prints that rollback command and exits. It does not execute rollback automatically. An operator must assess the failure and take the recovery action.

Cloud Run's traffic controls provide the mechanism for sending requests back to an earlier revision. Decide in advance who can initiate that action, which evidence should trigger it, and how the restored application will be verified. Keep recovery instructions available before promotion rather than reconstructing them under pressure.

Moving traffic back does not undo a database migration, reverse an external message or restore a modified business record. Before releasing a stateful change, check whether the previous application remains compatible with the new data shape and whether recovery needs a separate data procedure.

The same reasoning applies to separately deployed services. IHP's website and contact backend have separate release paths. When a frontend request contract changes, backend compatibility must be verified and the deployment sequence coordinated; rolling back the website alone may not resolve an incompatible backend change.

A useful release record is compact enough to complete during delivery and precise enough to support an incident review. Keep sensitive configuration out of it, link to controlled build and operational evidence, and distinguish completed checks from recommendations awaiting implementation.

For an existing Cloud Run application, IHP Technology can apply the same approach used in its website tooling: examine the current release path, connect source and artifact identity, establish checks around traffic promotion, and document recovery. The checklist below provides a starting acceptance standard that can be adjusted to the application's actual workflows.