Emulator does not use default project, if multiple projects are found in .firebaserc (and firebase use <alias> requires a valid login session)

[exetico]

[REQUIRED] Environment info

firebase-tools: 13.16.0

Platform: macOS, Ubuntu

[REQUIRED] Test case

• Initiate a new Firebase solution
• Add more than one project to .firebaserc for the emulator
• Start the emulator (I'm using firebase emulators:exec 'npm run __jest' right now)
• See that it prompts with No project active, but project aliases are available.

⚠  emulators: You are not currently authenticated so some features may not work correctly. Please run firebase login to authenticate the CLI.
i  emulators: Starting emulators: auth, functions, firestore, hosting, pubsub
i  emulators: Shutting down emulators.

Error: No project active, but project aliases are available.

Run firebase use <alias> with one of these options:

  default (projectname-dev)
  dev (projectname-dev)
  staging (projectname-staging)
  prod (projectname-prod)
  prod-legacy (projectname-prod-legacy)

[REQUIRED] Steps to reproduce

Do above test-case to reproduce the scenario.

I'm facing the problem as part of a GitHub Workflow solution, where I run Jest in the emulated Firebase suite, and don't want to login, just in order to run the test.

However, having multiple projects in .firebaserc will trigger a "select a active project" prompt, but, using firebase use requires a login. Stripping down .firebaserc to only contain a default project, does fix the problem, as it's just starting the emulator, without promping me to set a active project.

[REQUIRED] Expected behavior

• I expect the emulator to start with the default project, even though, I've not executed firebase use. Else, I'd like to force it to do so, with a flag (or similar).

[REQUIRED] Actual behavior

• it complains about no active project currently set

Alternative solution

If I was able to execute firebase use default without having to deal with login, it was easy to work around.
But right now,, I'm unable to execute firebase use <alias> without a env where I'm logged in.

In other words, my only work-around right now, is simply to have a .firebaserc file with:

{
  "projects": {
    "default": "projectname-dev"
  }
}

As the emulator does pick up the default project in this scenario, and no other projects are listed in .firebaserc.

But, maybe I've missed yet another alternative solution? It just a bit odd that having multiple projects in .firebaserc does end up as a problem, which I'm currently unable to fix, without logging in.

The firebase emulators:exec does not give me a option to add "--project", which would also be another possible way of controlling this.

[aalej]

Hey @exetico, thanks for providing a detailed report and for sharing what you've tried so far! I think you should be able to pass a value to the --project option when running firebase emulators:exec. Just to verify, are there any errors being raised when you run firebase emulators:exec "npm run test" --project PROJECT_ID?

I'm currently able to run the firebase emulators:exec "npm run test" --project PROJECT_ID command in a GitHub Actions Workflow. I created this repo to try and replicate the setup you have. Let me know if I'm missing anything here or if I've made a mistake in the setup.

[exetico]

I'm currently able to run the firebase emulators:exec "npm run test" --project PROJECT_ID command in a GitHub Actions Workflow. I created this repo to try and replicate the setup you have. Let me know if I'm missing anything here or if I've made a mistake in the setup.

You're right! --project PROJECT_ID actually works. Thanks! I did test that previously, after running the firebase emulators:exec --help, but I must have mistyped something, or forgot saving the file, or similar.

Maybe--project should be listed as part of the --help?

firebase emulators:exec --help
Usage: firebase emulators:exec [options] <script>

start the local Firebase emulators, run a test script, then shut down the emulators

Options:
  --only <emulators>           only specific emulators. This is a comma separated list of emulator names. Valid options are: ["auth","functions","firestore","database","hosting","pubsub","storage","eventarc","dataconnect","tasks"]
  --inspect-functions [port]   emulate Cloud Functions in debug mode with the node inspector on the given port (9229 if not specified)
  --import [dir]               import emulator data from a previous export (see emulators:export)
  --export-on-exit [dir]       automatically export emulator data (emulators:export) when the emulators make a clean exit (SIGINT), when no dir is provided the location of --import [dir] is used
  --log-verbosity <verbosity>  One of: DEBUG, INFO, QUIET, SILENT.
  --ui                         run the Emulator UI
  -h, --help                   output usage information

With that said: The original issue, where I'm unable to run with the "default" project, if multiple projects listed in .firebaserc are still here; the firebase use <project_alias does require me to login, and it's not "just" falling back to the default project. But if the .firebaserc only contains the default project, it's happily continuing with the default project.

I'll use --project as a workaround by setting that as part of the executing, but I'd personally expect a firebase project to be able to use the "default" project, even though, it's not previously set, like it's already do, if only a single project are found in .firebaserc. At least for the emulators. I get that it's maybe not that good to just fallback to a default project, in a deployment scenario (where use have not been executed`).

[google-oss-bot]

Hey @exetico. We need more information to resolve this issue but there hasn't been an update in 7 weekdays. I'm marking the issue as stale and if there are no new updates in the next 3 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

[aalej]

Thanks for the feedback, just providing a quick update on this based on our discussions with the team.

Maybe--project should be listed as part of the --help?

Yes, we agree with you here, we should definitely update the output of --help to include the --project option to provide clearer instructions on how to use the command.

With that said: The original issue, where I'm unable to run with the "default" project, if multiple projects listed in .firebaserc are still here; the firebase use <project_alias does require me to login, and it's not "just" falling back to the default project. But if the .firebaserc only contains the default project, it's happily continuing with the default project.

Similar to what you mentioned, we think that falling back to using the default project when no project is explicitly set would be the expected behavior here.

In case we may have misunderstood your feedback in any way, please let us know.

[exetico]

As this point, we're aligned.

1. Add details about --project for the command
2. Secure that, if no project are selected, it will default to the default project, even though, the .firebaserc file contains more projects than one (that's already the working logic, if there's only one project in firebaserc, so it's just a question about also doing that, if there's multiple projects).

[joehan]

Fixed the main issue here in #7804, which released yesterday with 13.21.0. The help text fix will come later - turns out the CLI pacakge we use (commander) makes this slightly more difficult than expected.

[exetico]

Thank you joehan. That's much appreciated.