infra(api): carry the frontend deploy's three edges back to the API

[MarkusNeusinger]

api/cloudbuild.yaml invented the candidate rollout. app/cloudbuild.yaml then improved it in #11207, and the improvements never came back to the file they came from. Three of them do here — nothing else in the deploy changes.

1. :latest was published before the smoke

push-latest waited on build-image. The tag therefore reached Artifact Registry before the candidate was even deployed, let alone probed: a build whose smoke failed still left :latest pointing at the image that failed it — and :latest is what a human reaches for when they want "the image that is running".

It now waits on promote, exactly as the frontend's does. Still not a guarantee across concurrent builds (two overlapping deploys race for the tag), which is why the deploy step pulls :$BUILD_ID and never :latest; the comment says so at the step.

2. The candidate tag was checked once, not twice

candidate is a shared tag. The smoke resolved it, asserted it named this build's revision, then probed — and a concurrent build moving the tag between that assertion and the last probe would leave this build promoting a revision it only believed it had smoked.

The tag is now re-asserted after the probes. A competing build only ever tags its own revision and never ours back, so seeing our revision at both ends means every probe in between hit it. Same reasoning and same wording as app/cloudbuild.yaml.

The API is the service where this matters most: its probes are the ones that touch Cloud SQL and the admin gate.

3. curl … | grep -q is a trap that had not sprung yet

curl -fsS $RETRY "${HDR[@]}" "$URL/libraries" | grep -q '"libraries"'

grep -q exits at the first match and SIGPIPEs curl. The pipeline only ever passed because -ceu carries no pipefail — the day someone adds set -o pipefail as a hardening pass, every deploy goes red for reasons that have nothing to do with the deploy.

The probes now go through the same expect helper the frontend build uses: fetch to a file, grep -qF, and on failure say which probe failed and what was missing. /health keeps a bare variant (expect_bare) because reaching it without the origin header is precisely what its gate exemption has to prove.

Verification

No Cloud Build dry-run exists for this, so the script was checked out of band:

• YAML parses; the bash step was extracted and expanded the way Cloud Build expands it ($$ → $, substitutions resolved) — bash -n clean, no leftover $$.
• The helpers were then run against a local HTTP server on three paths: happy path (OK: /health, OK: /libraries), a needle that is not in the body (needle missing must fail (/libraries is missing: NOT_THERE), exit 1), and a 404 (candidate did not serve /nope, exit 1).
• HDR=() expanded as "${HDR[@]}" under set -u was confirmed safe on bash 5.2 — the cloud-sdk builder's bash.

The real proof is the next deploy-api build, which runs the whole chain.

🤖 Generated with Claude Code

https://claude.ai/code/session_01UEScQMZFvxxNNyNJYryfa3

[Copilot]

🟡 Changes recommended

Deployment guarantees are overstated, and the changelog contains contradictory rollout descriptions.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR hardens the API’s candidate-based Cloud Run deployment.

Changes:

• Publishes :latest only after promotion.
• Adds clearer smoke-probe helpers.
• Rechecks the candidate tag after probing.

File summaries

File	Description
api/cloudbuild.yaml	Strengthens deployment sequencing and smoke checks.
CHANGELOG.md	Documents the rollout changes.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 3
• Review effort level: Balanced

---

💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.