Gate backend prod deploys on blessing

[Git-on-my-level]

Summary

• add typed override inputs to gcp_backend.yml
• gate only prod backend deploys on the exact python-backend blessing release
• compute deploy image/revision identity from the checked-out ref instead of raw GITHUB_SHA
• add a workflow policy guard so the gate stays before GCP auth/build/deploy mutations

Stack

1. Add release blessing surface registry #9201 — Release blessing surface registry
2. Add Python backend blessing command #9202 — Python backend blessing command
3. Gate backend prod deploys on blessing #9203 — this PR
4. Require backend blessing for desktop promotion #9204 — Desktop promotion requires backend blessing

Verification

• python3 .github/scripts/check-backend-prod-promotion-policy.py
• python3 .github/scripts/test_check_python_backend_blessing.py
• python3 .github/scripts/test_release_blessing.py
• YAML parse check for .github/workflows/gcp_backend.yml
• pre-push hook passed for the full stack, including OpenAPI checks

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 6c20f0e12e

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[cubic-dev-ai]

2 issues found across 2 files

Confidence score: 1/5

• In .github/workflows/gcp_backend.yml, the prod blessing check is attached to repair-traffic instead of deploy, so the default mode: deploy path can promote to prod without validation; merging as-is creates a direct policy bypass on normal releases — move the blessing gate into the deploy job (or a shared prerequisite) before merging.
• In .github/scripts/check-backend-prod-promotion-policy.py, the text.find()-based ordering logic can treat checks in different jobs as if they were in the same sequence, so the guard may report compliant workflows that still bypass enforcement; merging as-is leaves the protection unreliable even after workflow edits — update the parser to validate ordering within the correct job scope and add a failing test for this bypass case before merging.

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[Git-on-my-level]

Reviewed the outstanding Codex P1 review thread ("Move backend blessing validation into deploy job"). No code change was needed — the thread was left on an earlier diff and is already addressed by the current code on this branch:

• The Validate prod Python backend blessing step runs inside the deploy job (gated on mode == 'deploy'), positioned before Google Auth, the Docker image build, and the Cloud Run deploy steps. An unblessed SHA cannot reach prod via the normal deploy path.
• The repair-traffic job (mode == 'repair-traffic-only') contains no deploy mutations, so no blessing gate applies there by design.
• The parallel Cubic P0 thread raising the same concern was already resolved.

Verification run locally against this branch (all passed):

• python3 .github/scripts/check-backend-prod-promotion-policy.py — policy OK (confirms the blessing step precedes auth/build/deploy mutations)
• python3 .github/scripts/test_check_python_backend_blessing.py — tests OK
• python3 .github/scripts/test_release_blessing.py — tests OK
• YAML parse check for .github/workflows/gcp_backend.yml — OK

The outdated Codex P1 thread has been resolved.

[kodjima33]

Gate backend prod deploys on blessing — approve-only; modifies gcp_backend.yml deploy workflow, needs Nik.

[Git-on-my-level]

Will wait for existing blessing infra to bake first

[Git-on-my-level]

Superseded by #9399.

#9201/#9202 already landed on main; #9399 rebuilds only the remaining prod deploy gate + policy guard on current main (without the stale branch deletions). Closing this PR in favor of that one.

[Git-on-my-level]

Closing as superseded by #9399.

[github-actions]

Hey @Git-on-my-level 👋

Thank you so much for taking the time to contribute to Omi! We truly appreciate you putting in the effort to submit this pull request.

After careful review, we've decided not to merge this particular PR. Please don't take this personally — we genuinely try to merge as many contributions as possible, but sometimes we have to make tough calls based on:

• Project standards — Ensuring consistency across the codebase
• User needs — Making sure changes align with what our users need
• Code best practices — Maintaining code quality and maintainability
• Project direction — Keeping aligned with our product principles and locked invariants

Before your next PR, please skim:

• PRODUCT.md — product north star
• Product invariants — locked rules (shared chat, memory tiers, agent control plane, integrations, brand)

If this was declined for direction or taste, maintainers should cite an invariant ID or open a proposed one — ask if that citation is missing.

Your contribution is still valuable to us, and we'd love to see you contribute again in the future! If you'd like feedback on how to improve this PR or want to discuss alternative approaches, please don't hesitate to reach out.

Thank you for being part of the Omi community!