Non-interactive version of firebase init

[samtstern]

Right now there is no way to do firebase init --project=foo {product} within a script. Since hand-crafting a firebase.json file is a lot of guesswork it could be cool to make firebase init --noninteractive accept all defaults.

@mbleigh is that possible or reasonable?

[mbleigh]

We've always considered init to be an explicitly interactive command, but maybe we could do something like npm init -y and add a -y/--confirm that is equivalent to selecting all the defaults. I'm not strongly opposed to it.

[GabeWeiss]

Not being able to automate Firestore initialization means it can't be used in any build script setup. This has been the origination of where this request came from. I've got a demo that uses Firestore for which I need a build setup/script and currently I have a rather ugly "When it hits this part of the script, just hit return to accept the defaults to continue the script". I was particularly surprised because there IS a --non-interactive flag, it's just ignored.

Having a flag to accept all defaults would be perfect.

[samtstern]

@GabeWeiss agree with your feedback however I think the current best practice is to have a firebase.json somewhere in version control. That's 90% of what firebase init does (the other 10% is choose your default project).

So if you have a firebase.json as part of your demo, there's no need to ever run firebase init.

[GabeWeiss]

I'll test, but before just to record my flow (currently) in order to go from fresh GCP project to having Firestore able to be used is as follows:

1. gcloud app create --region=us-west2 (Note, there's a problem with using us-central1 which is the default because in a fresh project, the default AppEngine hasn't been created yet either, so we need to do that, but AppEngine's default region is us-central, and Firestore's is us-central1. If they don't line up, creation fails on CLI)
2. gcloud alpha firestore databases create --region=us-west2
3. Create a tmp dir for Firestore initialization (firestore_setup) and cd into it
4. firebase projects:addfirebase <project_id> (this is one of the missing pieces in gcloud firestore which is hopefully going to be added in the future)
5. firebase init firestore -P <project_id>
6. cp ../firestore.indexes ./firestore.indexes.json (this is the ONLY way I can currently re-create the needed indexes in Firestore, the indexes command doesn't allow for the type of indexes I need for the queries we run)
7. firebase deploy --only firestore:indexes

So, to be clear, you're saying, that if I save off the firebase.json after I've run that init in step 5, save that into source control, and after I've created my temporary directory, also copy over the firebase.json into the tmp directory, I don't have to run init at all, I can go straight to deploying the indexes? Do I need to do a "full deploy" rather than specifying the --only flag in that case?

[samtstern]

1. Yes if your directory has firebase.json and the indexes/rules files you can right away do firebase -P <project id> deploy --only firestore
2. What are the indexes that you can't create with "the indexes command". I don't quite understand that feedback.
3. Have you tried doing firebase projects:addfirebase earlier in the flow? Maybe even do it first. I believe that might let you skip the AppEngine creation part but I am not sure.
4. I see no reason why there's a tmp directory needed in all of this.

[GabeWeiss]

1. Okay, I'll give that a go
2. The index from the query creates a query scope of "Collection group" but the indexes command from CLI can't do that that I can figure out. I could only ever create a Query scope of "Collection" using CLI. My queries fail in the script with the error message about creating the indexes if I left it as "Collection" and not "Collection group" scoping. I admit I don't fully understand the difference... I just know it worked if I had it as Collection group and didn't if it was only Collection. So I did what works.
3. I have, and it fails telling me there's no AppEngine and to go do that first. Now, I CAN do this all from the console and it all works fine. I.e. I can, from the console with a fresh GCP project with no AppEngine, create/enable Firestore and it just works (I assume behind the scenes it's creating the default AppEngine for me in the appropriate region)
4. It's not strictly necessary, but it's to make my source control easier by preserving my files without risk of overwrite, and being able to easily .gitignore the setup directory for proper cleanup to prevent pollution of the source control with project-specific information.

[GabeWeiss]

Hokay, I can skip the init if I also grab the firestore.rules post-init looks like. I haven't fully done any writing to the db, but it at least didn't fail the deploy, so that's a good step.

I still would advocate a silent option being added, since I think an "accept all defaults" is pretty standard in the db space, but this at least gets me around my ugly keyboard mashing for my build script. :)

[jherman]

@GabeWeiss

2. The index from the query creates a query scope of "Collection group" but the indexes command from CLI can't do that that I can figure out. I could only ever create a Query scope of "Collection" using CLI. My queries fail in the script with the error message about creating the indexes if I left it as "Collection" and not "Collection group" scoping. I admit I don't fully understand the difference... I just know it worked if I had it as Collection group and didn't if it was only Collection. So I did what works.

Were you ever able to figure out how to specify query scope of "collection group" vs "collection" via CLI? Running into that issue right now.

[GabeWeiss]

I wasn't, no. To be fair I haven't been trying since these comments though as I've shifted onto other projects. To my knowledge this hasn't changed (caveat, I'm not on or work directly with this team so it MIGHT have, I just don't know because I haven't heard it come up).

[jherman]

@GabeWeiss Thanks for the reply. I think you are right that it's still not supported still. the --query-scope is undocumented from what I can tell and still only accepts only "collection" as an argument. I've tried several different values to see if there was any hidden acceptable values for collection groups, but none work. Seems real odd this hasn't been addressed.

[evamaxfield]

Has anyone in this thread been able to also setup / initialize firebase storage via the command list above?

[LkyYuen]

is --non-interactive works now?

[evamaxfield]

is --non-interactive works now?

It does not. It asks for input on the "which file should be used for rules"

[cg219]

This is a big issue if trying to create a RealtimeDB. Seems to be no way to do this non-interactively. Is there another way to create a default RealtimeDB with gcloud instead of firebase cli ??

[reinis-s]

Hey, I would like to provide an alternative viewpoint. In 2022 any self-respecting OPS/Organisation automate infra, including DB creation. I can work CLI tool if there is no normal terraform support. But it seems that this official policy by Firebase and all of its sub-projects prevent fully automated provisioning.

I do love the product, but operation support is seriously lacking.