Support Firebase SDK auto-initialization for Cloud Run services

[falahat]

Description

Links a Firebase Web App to a Cloud Run service so Firebase SDKs auto-initialize. The app ID is saved in the service's firebase.google.com/app-id annotation.

• firebase init run asks which web app to link (default: create a new one). A new app is created only after all questions are answered, and init fails if it can't create one. An existing service keeps its app.
• firebase run:services:update <service> --app <appId> links an app; --clear-app unlinks it.
• On deploy, the CLI fetches the linked app's config:
  • Build: sets FIREBASE_WEBAPP_CONFIG and FIREBASE_CONFIG.
  • Runtime: sets FIREBASE_CONFIG on the container, and removes it when unlinking.
  • Both always come from the linked app. To override auto-init, users pass their own config in code.
  • If the app can't be fetched, the deploy fails.
• When a deploy links an app, the CLI checks whether the runtime service account has roles/firebase.sdkAdminServiceAgent. If not, or if it can't check, it prints the gcloud command to grant it. It never changes IAM.

Scenarios Tested

• Unit tests: npx mocha src/deploy/run/*.spec.ts src/init/features/run.spec.ts
• Manual:
  • init: picking an existing app links it without creating one; "Create a new web app" creates one only after the questions; quitting partway leaves nothing behind.
  • The client and Admin SDKs initialize from the linked app. A plain deploy keeps the link, --app switches it, --clear-app removes it, and a bad --app fails before deploying.
  • Without the role, Admin SDK Storage and Auth calls fail; the printed command fixes it.

Sample Commands

firebase init run
firebase run:services:update my-service --app
firebase run:services:update my-service --clear-app

[falahat]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces support for linking and clearing a Firebase Web App associated with a Cloud Run service to enable SDK auto-initialization. It adds --app and --clear-app options to the update command, automatically links web apps during initialization, and injects the configuration into environment variables. Feedback on these changes includes wrapping getOrCreateWebApp in a try-catch block to prevent crashes from permission errors, skipping redundant redeployments when the app ID is already linked, using hasOwnProperty instead of the in operator to avoid prototype pollution, and replacing numeric length checks in object spreads to prevent evaluating to { ...0 }.

[gemini-code-assist]

Code Review

This pull request introduces the ability to link and clear a Firebase Web App for Cloud Run services, enabling Firebase SDK auto-initialization. It adds --app and --clear-app options to the run:services:update command, updates firebase init run to automatically associate a Web App, and injects the corresponding FIREBASE_CONFIG and FIREBASE_WEBAPP_CONFIG environment variables during preparation and deployment. The review feedback highlights two important improvements: first, wrapping the getOrCreateWebApp call in firebase init run with a try-catch block to prevent crashes on network or permission failures; second, throwing a FirebaseError if a newly requested Web App lookup fails during deployment, ensuring the service is not left in a partially configured state.

[falahat]

/gemini review

[gemini-code-assist]

Code Review

This pull request adds support for linking and clearing a Firebase Web App on Cloud Run services to enable SDK auto-initialization, updating the CLI commands, deployment pipeline, and initialization flows accordingly. The feedback recommends moving the resolution of the default service account and project number inside the try-catch block to prevent deployment crashes, correcting the arguments passed to getProjectNumber, and utilizing the getError utility instead of manual type checks to safely handle unknown error types.

[abhis3]

Nice! Happy to merge this as is since it's a prototype and we can clean it up later. Heads up you might need to squash your commits. Left a few AI comments that I thought were reasonable when comparing it to this design doc, feel free to fix/ignore as necessary. I don't think any are blocking the merge here.

Nits:

• RUN_PERMISSIONS doesn't include firebase.clients.list/get or resourcemanager.projects.getIamPolicy, so CI identities pass the precheck and then fail mid-prepare.

• A 403 on the IAM read is reported as "Failed to grant…".

• annotations is in the update mask on every deploy, a full read-modify-write with no etag. Maybe include it only when the link changes.

• appId and firebaseConfig can diverge; a single autoInit?: {appId, firebaseConfig} would prevent that.

• The PR description is a bit stale: it says init prompts, it says a failed lookup only warns, and the error text has changed.