fix: remove PINECONE from prod deploy (not needed)

[beastoin]

Summary

• Removes PINECONE_API_KEY and PINECONE_HOST from the prod deploy secrets block
• Both are Option<String> in Rust config — only used for rewind screen search
• Were never on prod Cloud Run before
• All other secrets kept as GCP Secret Manager refs (manager created the missing ones)

---

by AI for @beastoin

[greptile-apps]

Greptile Summary

This PR modifies the production Cloud Run deploy step in .github/workflows/desktop_auto_release.yml to remove 7 Secret Manager bindings (GEMINI_API_KEY, FIREBASE_API_KEY, REDIS_DB_HOST, REDIS_DB_PORT, REDIS_DB_PASSWORD, PINECONE_API_KEY, PINECONE_HOST) from the secrets: block, with the intent of managing these as manually-set plaintext env vars on the Cloud Run service instead.

Issues found:

• Critical — env vars will be wiped on every deploy: The google-github-actions/deploy-cloudrun@v2 action uses --set-env-vars (overwrite mode) by default for its env_vars input. This means every deployment triggered by a push to main will replace all Cloud Run env vars with only those listed in the env_vars: block (FIREBASE_PROJECT_ID, GOOGLE_APPLICATION_CREDENTIALS, AGENT_GCS_BUCKET). The manually-set GEMINI_API_KEY, FIREBASE_API_KEY, REDIS_DB_HOST, REDIS_DB_PORT, and REDIS_DB_PASSWORD will be wiped on the next deploy, breaking the service. The PR description's rationale ("the action uses --update-secrets not --set-secrets") applies only to the secrets: block, not to env_vars. To fix this, add env_vars_update_policy: merge to the deploy step, or define these variables explicitly in the workflow.

• Security concern — REDIS_DB_PASSWORD as plaintext: A database password is being moved from encrypted Secret Manager storage to a plaintext Cloud Run env var, which is visible in the Cloud Run console and to identities with viewer/admin IAM roles. Passwords should remain in Secret Manager.

• Dev/prod asymmetry: The development job still manages all 7 removed variables as Secret Manager references. This inconsistency is not documented and could mask issues.

Confidence Score: 1/5

• Not safe to merge — the approach will cause production env vars to be wiped on every deploy, and downgrades a database password from Secret Manager to plaintext.
• The core assumption of the PR (that manually-set env vars are preserved across deploys) is incorrect given how deploy-cloudrun@v2 handles env_vars by default. Merging as-is will result in the production service losing GEMINI_API_KEY, FIREBASE_API_KEY, REDIS_DB_HOST, REDIS_DB_PORT, and REDIS_DB_PASSWORD on every subsequent deploy, causing runtime failures. Additionally, moving REDIS_DB_PASSWORD to a plaintext variable is a security regression.
• .github/workflows/desktop_auto_release.yml — specifically the deploy-desktop-backend-prod job's env_vars and secrets blocks.

Important Files Changed

Filename	Overview
.github/workflows/desktop_auto_release.yml	Removes 7 Secret Manager bindings from the prod Cloud Run deploy step, relying on manually-set plaintext env vars — but env_vars uses --set-env-vars (overwrite) by default, so those manually-set vars will be wiped on every deploy; also downgrades REDIS_DB_PASSWORD from Secret Manager to plaintext.

Sequence Diagram

sequenceDiagram
    participant GH as GitHub Actions
    participant CR as Cloud Run (Prod)
    participant SM as Secret Manager

    Note over GH,SM: Before this PR (working state)
    GH->>CR: deploy-cloudrun (--set-env-vars FIREBASE_PROJECT_ID, ...)<br/>+ --set-secrets GEMINI_API_KEY, REDIS_DB_PASSWORD, FIREBASE_API_KEY,<br/>PINECONE_API_KEY, REDIS_DB_HOST, REDIS_DB_PORT, PINECONE_HOST,<br/>ENCRYPTION_SECRET, DEEPGRAM_API_KEY, ...
    CR->>SM: Resolve all 11 secret refs at container startup
    SM-->>CR: All values injected as env vars

    Note over GH,SM: This PR — intended behavior
    GH->>CR: deploy-cloudrun (--set-env-vars FIREBASE_PROJECT_ID, ...)<br/>+ --set-secrets ENCRYPTION_SECRET, DEEPGRAM_API_KEY,<br/>ANTHROPIC_API_KEY, GOOGLE_CALENDAR_API_KEY
    CR->>SM: Resolve 4 remaining secret refs
    Note over CR: Expects GEMINI_API_KEY, REDIS_DB_HOST etc.<br/>to be present as pre-set plaintext env vars

    Note over GH,CR: Actual behavior — env vars wiped each deploy
    GH->>CR: --set-env-vars FIREBASE_PROJECT_ID=...,<br/>GOOGLE_APPLICATION_CREDENTIALS=..., AGENT_GCS_BUCKET=...
    Note over CR: ⚠️ --set-env-vars REPLACES all env vars<br/>Manually-set GEMINI_API_KEY, REDIS_DB_HOST,<br/>REDIS_DB_PORT, REDIS_DB_PASSWORD, FIREBASE_API_KEY<br/>are WIPED on every deploy
    CR-->>GH: Service starts missing required variables → runtime errors

Loading

Comments Outside Diff (2)

1. .github/workflows/desktop_auto_release.yml, line 64-86 (link)

   Dev/prod secrets inconsistency

   The deploy-desktop-backend (development) job on line 76–86 still manages GEMINI_API_KEY, REDIS_DB_PASSWORD, FIREBASE_API_KEY, PINECONE_API_KEY, REDIS_DB_HOST, REDIS_DB_PORT, and PINECONE_HOST as Secret Manager references. After this PR, the production job only manages 4 secrets.

   This asymmetry means these variables are sourced differently in dev vs. prod, which is unusual and could mask issues (e.g. a Secret Manager entry expiring in dev would go unnoticed until something in the secret-free prod path breaks).

   If the intent is that these are genuinely non-sensitive and should be plaintext everywhere, the same change should apply to the dev job. If they remain secrets in dev, it should be documented why the security posture differs between environments.

2. .github/workflows/desktop_auto_release.yml, line 129-144 (link)

   Manually-set env vars will be wiped on every deploy

   The PR description relies on the assumption that the google-github-actions/deploy-cloudrun@v2 action preserves manually set env vars across deployments. However, the env_vars input uses --set-env-vars by default (the overwrite policy), which replaces all Cloud Run env vars with only those listed in the env_vars: block on each deploy.

   This means GEMINI_API_KEY, FIREBASE_API_KEY, REDIS_DB_HOST, REDIS_DB_PORT, and REDIS_DB_PASSWORD — set manually via the gcloud command described in the PR description — will be wiped on the next push to main that touches desktop/, leaving the production service without these required variables and likely causing a crash or degraded functionality.

   The claim that variables are "preserved across deploys since the action uses --update-secrets not --set-secrets" applies only to the secrets: block (Secret Manager bindings), not to env_vars:.

   To safely preserve manually-injected env vars, add env_vars_update_policy: merge to the deploy step so it uses --update-env-vars instead of --set-env-vars. This is a built-in input of deploy-cloudrun@v2. Alternatively, define the moved variables explicitly in the env_vars: block (sourced from GitHub Actions variables or secrets) so they are always present in the workflow config.

_{Last reviewed commit: "fix: prod deploy — k..."}

[greptile-apps]

REDIS_DB_PASSWORD moved to plaintext

REDIS_DB_PASSWORD is a database credential being moved from GCP Secret Manager (encrypted at rest, access-controlled via IAM) to a plaintext Cloud Run environment variable visible in the console, deployment logs, and to any identity with roles/run.viewer or roles/run.admin. Passwords should not be downgraded to plaintext configuration, even within a managed cloud service.

REDIS_DB_PASSWORD should remain in Secret Manager and stay in the secrets: block. If the original Secret Manager entry no longer exists in the prod project, it should be re-created rather than replaced with a plaintext value.

[beastoin]

lgtm