fix: deployed gdrive OAuth uses real Google creds, not emulator mocks

[jodeleeuw]

Problem

Connecting Google Drive on datapipe-test.web.app sent users to a localhost/127.0.0.1 authorize URL instead of Google's consent screen.

Root cause: Firebase loads functions/.env.datapipe-test on both firebase deploy and the emulator. That file held the emulator mock values (127.0.0.1 token/authorize servers, test-client-id, localhost:3000 redirect), so the deployed functions handed those to the browser.

Fix

Split emulator vs. deployed config along Firebase's emulator-only .env.local seam (.env.local is loaded only by the emulator, never deployed, and takes precedence):

• functions/.env.local (new, committed, never deployed) — mock values for local dev + CI. Un-ignored in .gitignore so a fresh checkout works with no setup; all values are non-secret test dummies.
• functions/.env.datapipe-test — now the real deployed config: Google client id + https://datapipe-test.web.app/oauth2/connect. Authorize/token/api-base URLs left unset so real Google defaults apply.
• firebase-deploy-test.yml — injects GDRIVE_CLIENT_SECRET from the new TEST_GDRIVE_CLIENT_SECRET GitHub secret.

Prereqs already done

• Drive API enabled on datapipe-test
• OAuth consent screen + Web client created (redirect https://datapipe-test.web.app/oauth2/connect, scope drive.file)
• TEST_GDRIVE_CLIENT_SECRET GitHub secret set

Verification

oauth-connect-emulator, gdrive-emulator, resolve-token-gdrive suites pass (24/24) — .env.local overrides shadow the real values under the emulator, so CI stays green.

Merging this to test triggers firebase-deploy-test.yml, which deploys the functions with real Drive creds.

Note: .env.datapipe-test still carries a dummy TOKEN_ENCRYPTION_KEY that overrides the real FIRESTORE_KEY_TEST secret on deploy (same pre-existing leak pattern). Left as-is here to avoid orphaning already-encrypted test tokens — worth a separate follow-up.

🤖 Generated with Claude Code