Allow apphosting:backends:create to be called with --non-interactive (#9025)

Author: annajowang

src/apphosting/backend.ts

@@ -73,44 +73,63 @@ async function awaitTlsReady(url: string): Promise<void> {
  */
 export async function doSetup(
   projectId: string,
-  webAppName: string | null,
-  serviceAccount: string | null,
+  nonInteractive: boolean,
+  webAppName?: string,
+  backendId?: string,
+  serviceAccount?: string,
+  primaryRegion?: string,
+  rootDir?: string,
 ): Promise<void> {
   await ensureRequiredApisEnabled(projectId);
 
   // Hack: Because IAM can take ~45 seconds to propagate, we provision the service account as soon as
   // possible to reduce the likelihood that the subsequent Cloud Build fails. See b/336862200.
-  await ensureAppHostingComputeServiceAccount(projectId, serviceAccount);
+  await ensureAppHostingComputeServiceAccount(projectId, serviceAccount ? serviceAccount : null);
 
   // TODO(https://github.com/firebase/firebase-tools/issues/8283): The "primary region"
   // is still "locations" in the V1 API. This will change in the V2 API and we may need to update
   // the variables and API methods we're calling under the hood when fetching "primary region".
-  const location = await promptLocation(
-    projectId,
-    "Select a primary region to host your backend:\n",
-  );
+  let location = primaryRegion;
+  let gitRepositoryLink: GitRepositoryLink | undefined;
+  let branch: string | undefined;
+  if (nonInteractive) {
+    if (!backendId || !primaryRegion) {
+      throw new FirebaseError("nonInteractive mode requires a backendId and primaryRegion");
+    }
+  } else {
+    if (!location) {
+      location = await promptLocation(projectId, "Select a primary region to host your backend:\n");
+    }
+    if (!backendId) {
+      logBullet(`${clc.yellow("===")} Set up your backend`);
+      backendId = await promptNewBackendId(projectId, location);
+      logSuccess(`Name set to ${backendId}\n`);
+    }
+    if (!rootDir) {
+      rootDir = await input({
+        default: "/",
+        message: "Specify your app's root directory relative to your repository",
+      });
+    }
+
+    gitRepositoryLink = await githubConnections.linkGitHubRepository(projectId, location);
+    // TODO: Once tag patterns are implemented, prompt which method the user
+    // prefers. We could reduce the number of questions asked by letting people
+    // enter tag:<pattern>?
+    branch = await githubConnections.promptGitHubBranch(gitRepositoryLink);
+    logSuccess(`Repo linked successfully!\n`);
+  }
+  // Confirm both backendId and location are set at this point
+  if (!location || !backendId) {
+    // This should not happen based on the logic above, but it satisfies the type checker.
+    throw new FirebaseError("Internal error: location or backendId is not defined.");
+  }
 
-  const gitRepositoryLink: GitRepositoryLink = await githubConnections.linkGitHubRepository(
+  const webApp = await webApps.getOrCreateWebApp(
     projectId,
-    location,
+    webAppName ? webAppName : null,
+    backendId,
   );
-
-  const rootDir = await input({
-    default: "/",
-    message: "Specify your app's root directory relative to your repository",
-  });
-
-  // TODO: Once tag patterns are implemented, prompt which method the user
-  // prefers. We could reduce the number of questions asked by letting people
-  // enter tag:<pattern>?
-  const branch = await githubConnections.promptGitHubBranch(gitRepositoryLink);
-  logSuccess(`Repo linked successfully!\n`);
-
-  logBullet(`${clc.yellow("===")} Set up your backend`);
-  const backendId = await promptNewBackendId(projectId, location);
-  logSuccess(`Name set to ${backendId}\n`);
-
-  const webApp = await webApps.getOrCreateWebApp(projectId, webAppName, backendId);
   if (!webApp) {
     logWarning(`Firebase web app not set`);
   }
@@ -120,13 +139,23 @@ export async function doSetup(
     projectId,
     location,
     backendId,
-    serviceAccount,
+    serviceAccount ? serviceAccount : null,
     gitRepositoryLink,
     webApp?.id,
     rootDir,
   );
   createBackendSpinner.succeed(`Successfully created backend!\n\t${backend.name}\n`);
 
+  // In non-interactive mode, we never connected the backend to a github repo. Return
+  // early and skip the rollout and setting default traffic policy.
+  if (nonInteractive) {
+    return;
+  }
+
+  if (!branch) {
+    throw new FirebaseError("Branch was not set while connecting to a github repo.");
+  }
+
   await setDefaultTrafficPolicy(projectId, location, backendId, branch);
 
   const confirmRollout = await confirm({

src/commands/apphosting-backends-create.ts

@@ -1,8 +1,8 @@
 import { Command } from "../command";
+import { FirebaseError } from "../error";
 import { Options } from "../options";
 import { needProjectId } from "../projectUtils";
 import { requireAuth } from "../requireAuth";
-import requireInteractive from "../requireInteractive";
 import { doSetup } from "../apphosting/backend";
 import { ensureApiEnabled } from "../gcp/apphosting";
 import { APPHOSTING_TOS_ID } from "../gcp/firedata";
@@ -14,19 +14,36 @@ export const command = new Command("apphosting:backends:create")
     "-a, --app <webAppId>",
     "specify an existing Firebase web app's ID to associate your App Hosting backend with",
   )
+  .option(
+    "--backend <backend>",
+    "specify the name of the new backend. Required with --non-interactive.",
+  )
   .option(
     "-s, --service-account <serviceAccount>",
     "specify the service account used to run the server",
     "",
   )
+  .option(
+    "--primary-region <primaryRegion>",
+    "specify the primary region for the backend. Required with --non-interactive.",
+  )
+  .option("--root-dir <rootDir>", "specify the root directory for the backend.")
   .before(requireAuth)
   .before(ensureApiEnabled)
-  .before(requireInteractive)
   .before(requireTosAcceptance(APPHOSTING_TOS_ID))
   .action(async (options: Options) => {
     const projectId = needProjectId(options);
-    const webAppId = options.app;
-    const serviceAccount = options.serviceAccount;
+    if (options.nonInteractive && (options.backend == null || options.primaryRegion == null)) {
+      throw new FirebaseError(`--non-interactive option requires --backend and --primary-region`);
+    }
 
-    await doSetup(projectId, webAppId as string | null, serviceAccount as string | null);
+    await doSetup(
+      projectId,
+      options.nonInteractive,
+      options.app as string | undefined,
+      options.backend as string | undefined,
+      options.serviceAccount as string | undefined,
+      options.primaryRegion as string | undefined,
+      options.rootDir as string | undefined,
+    );
   });

src/mcp/prompts/core/deploy.ts

@@ -43,14 +43,57 @@ ${prompt || "<the user didn't supply specific instructions>"}
 Follow the steps below taking note of any user instructions provided above.
 
 1. If there is no active user, prompt the user to run \`firebase login\` in an interactive terminal before continuing.
-2. If there is no \`firebase.json\` file and the current workspace is a static web application, manually create a \`firebase.json\` with \`"hosting"\` configuration based on the current directory's web app configuration. Add a \`{"hosting": {"predeploy": "<build_script>"}}\` config to build before deploying.
-3. If there is no active project, ask the user if they want to use an existing project or create a new one.
-  3a. If create a new one, use the \`firebase_create_project\` tool.
-  3b. If they want to use an existing one, ask them for a project id (the \`firebase_list_projects\` tool may be helpful).
-4. Only after making sure Firebase has been initialized, run the \`firebase deploy\` shell command to perform the deploy. This may take a few minutes.
-5. If the deploy has errors, attempt to fix them and ask the user clarifying questions as needed.
-6. If the deploy needs \`--force\` to run successfully, ALWAYS prompt the user before running \`firebase deploy --force\`.
-7. If only one specific feature is failing, use command \`firebase deploy --only <feature>\` as you debug.
+2. Analyze the source code in the current working directory to determine if this is a web app. If it isn't, end this process and tell the user "The /deploy command only works with web apps."
+3. Analyze the source code in the current working directory to determine if the app requires a server for Server-Side Rendering (SSR). This will determine whether or not to use Firebase App Hosting. Here are instructions to determine if the app needs a server:
+  Objective: Analyze the provided codebase files to determine if the web application requires a backend for Server-Side Rendering (SSR). Your final output must be a clear "Yes" or "No" followed by a brief justification.
+  Primary Analysis: package.json
+    This is the most critical step. If the package.json file is present, perform the following checks in order.
+    Parse package.json: Locate and read the contents of the package.json file.
+      Check Dependencies:
+        Examine the dependencies and devDependencies objects.
+        If any of the following packages are listed as keys, you can conclude the app uses SSR.
+          next
+          nuxt
+          @sveltejs/kit
+          @angular/ssr
+          remix
+        If a match is found, proceed directly to the Final Determination step.
+      Check Scripts: If no framework dependency was found, examine the scripts object.
+        Look for scripts (commonly start or serve) that execute a server process.
+        Examples include: "start": "next start", "start": "nuxt start", or "dev": "ng serve --ssr".
+        If such a script is found, conclude the app uses SSR and proceed to the Final Determination step.
+  Secondary Analysis: Project File Structure
+    Perform this analysis only if package.json is missing or inconclusive.
+    Scan for Framework-Specific Files and Directories: Search the codebase for the following patterns:
+      Next.js: A directory named app/ or pages/. Inside these, check for files containing the function name getServerSideProps.
+      Nuxt.js: A directory named server/.
+      SvelteKit: Any file ending with the .server.js suffix (e.g., +page.server.js, +layout.server.js).
+      Angular: A file named server.ts.
+    If any of these patterns are found, conclude the app uses SSR.
+  Final Determination
+    State Your Conclusion: Begin your response with a definitive "Yes" or "No".
+      Yes: The application requires a backend for SSR.
+      No: The application does not appear to require a backend for SSR and is likely a static or client-side rendered app.
+    Provide Justification: Follow your conclusion with a single sentence explaining the evidence.
+      Example (Yes): "Yes, the project requires SSR, as evidenced by the next dependency in package.json."
+      Example (Yes): "Yes, the project requires SSR, as evidenced by the presence of a +page.server.js file."
+      Example (No): "No, there are no dependencies or file structures that indicate the use of a server-side rendering framework."
+4. If there is no \`firebase.json\` file, manually create one based on whether the app requires SSR:
+  4a. If the app requires SSR, configure Firebase App Hosting:
+     Create \`firebase.json\ with an "apphosting" configuration, setting backendId to the app's name in package.json: \`{"apphosting": {"backendId": "<backendId>"}}\ 
+  4b. If the app does NOT require SSR, configure Firebase Hosting:
+    Create \`firebase.json\ with a "hosting" configuration. Add a \`{"hosting": {"predeploy": "<build_script>"}}\` config to build before deploying.
+5. Check if there is an active Firebase project for this environment (the \`firebase_get_environment\` tool may be helpful). If there is, proceed using that project. If there is not an active project, give the user two options: Use an existing Firebase project or Create a new one. Wait for their response before proceeding.
+  5a. If the user chooses to use an existing Firebase project, the \`firebase_list_projects\` tool may be helpful. Set the selected project as the active project (the \`firebase_update_environment\` tool may be helpful).
+  5b. If the user chooses to create a new project, use the \`firebase_create_project	\` tool. Then set the new project as the active project (the \`firebase_update_environment\` tool may be helpful).
+6. If firebase.json contains an "apphosting" configuration, check if a backend exists matching the provided backendId (the \`apphosting_list_backends\` tool may be helpful). 
+   If it doesn't exist, create one by running the \`firebase apphosting:backends:create --backend <backendId> --primary-region us-central1 --root-dir .\` shell.
+7. Only after making sure Firebase has been initialized, run the \`firebase deploy\` shell command to perform the deploy. This may take a few minutes.
+  7a. If deploying to apphosting, tell the user the deployment will take a few minutes, and they can monitor deployment progress in the Firebase console: \`https://console.firebase.google.com/project/<projectId>/apphosting\`
+8. If the deploy has errors, attempt to fix them and ask the user clarifying questions as needed.
+9. If the deploy needs \`--force\` to run successfully, ALWAYS prompt the user before running \`firebase deploy --force\`.
+10. If only one specific feature is failing, use command \`firebase deploy --only <feature>\` as you debug.
+11. If the deploy succeeds, your job is finished.
 `.trim(),
         },
       },