-
Notifications
You must be signed in to change notification settings - Fork 907
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
emulators shutting down immediately on Github CI if hosting emulator is not disabled since v11.14.2 #5114
Comments
I can confirm this issue. We are running firebase emulators inside docker container and it started failing with The container uses it like:
and then Debug logs shows:
|
I too am experiencing this running in a VS Code Dev container.
This immediately fails, and leaves the following in firebase-debug.log
|
I believe the jnizet@ As to the original error, I'm not positive that that same bug will fix the issue, but I'm a little suspicious that the CLI doesn't believe it's authenticated. I see @yuchenshi I see the following regarding ports and bindings. Is this suspicious?
|
Woo! I can replicate this. In short, a The "easy" workaround for now is going to be to authenticate the CLI in your CI. The "fast" fix causes other issues, so I'm going to have to track this down a bit more. |
Same error here too, @bkendall I'm running
Why would an emulator need to be authenticated?
Ready to test fixes any time. p.s. Is there any way for me to ask |
Running into this too on CircleCI: Here's the firebase-debug.log output:
|
@akauppi - there's definitely a valid case for what I'll more broadly describe as "offline emulator support". As more and more emulators have been supported, it's been 'easier' to test locally without needing to reach out to the internet. In years past, we've considered "being online" as a basic requirement for running (at that time, the only really available things:) the hosting and functions emulators - we required some configuration that was only stored server-side to be able to properly "emulate" Hosting (it's actually what the error here stems from), so we would fetch (and eventually locally cache) this data. As the emulators have evolved, more thought has started to go into making "offline mode" a... I guess the best way to describe it is a "supported feature". The fact that the emulators happen to work pretty well without authentication is surprising to me because (a) I don't do that (I'm usually deploying, which requires auth, but I'm always pleasantly surprised when I hear about new uses), and (b) it's not something we've explicitly worked to enable. There's definitely some work ahead of us to make sure that offline mode would work successfully for all cases the emulators are used for, but it's not something we explicitly support today. (I feel like I should say "by all means, if it keeps working, keep on doing it", but the truth of the matter is that because we've never specifically said "the emulators will work without an internet connection", I would just add "with caution"). All that said: there's a movement starting to make the emulator work without an internet connection. There's still some cases (like the before-mentioned configuration) that we may have to fetch once (or, in a CI environment, might have to be provided if required) but there's a lot of cases where it may not be necessary at all. I think it's totally fair to let us know if we make changes that break cases where the CLI isn't authenticated or we explicitly require an internet connection. Okay, long-winded response is long-winded. Sorry about that. But when it makes you "uneasy", I like to try and realize why and help provide context from our side. In my mind now, I can see the very easy step from "emulator" to "not needing to authenticate", and that helps me a lot in getting teams to do the work to make that more of a (official) reality (and break our biases about "everyone logs in or provides a service account"). |
@bkendall Just my two cents here: I also use the emulators expecting that they replace the actual production firebase environment, hence the lack of authentication. I understand where you came from, but IMHO, the whole point of using emulators is to be able to fully test an application during development without having to deploy anything, nor impact the production environment and data in any way. |
@bkendall You can find my use case at https://github.com/akauppi/GroundLevel-firebase-es/tree/next.sep22 |
Same issue for me, getting very tedious to remove the hosting lines from the config just to run the emulators. |
@jnizet 👍 'tis the goal! I think the "does it require authentication to the CLI" has simply been an overlooked question. But not any more! 🙂 Patch release is coming out Soon. |
Issue looks like the issue is resolved for my pipeline when using 11.4.3 and everything passes successfully. I see the new warnings:
|
Glad to hear that! Closing. |
Fixed here too. Thanks for the fix. |
Issue not fixed for me after update... is this just me?
|
@ariel-dao looks like you're having a different issue with the |
[REQUIRED] Environment info
firebase-tools: 11.14.2
Platform: Ubuntu
[REQUIRED] Test case
See this PR: jnizet/decouvertes-nature#399 and the build failing in this github action: https://github.com/jnizet/decouvertes-nature/actions/runs/3232299633/jobs/5292764406
[REQUIRED] Steps to reproduce
The github action starts the emulators with the command
[REQUIRED] Expected behavior
The emulators start (that was the case in previous version of firebase tools)
[REQUIRED] Actual behavior
They start, then shut down immediately (see output of the github action)
I've noticed that if I disable the hosting emulator (with --only), then the other emulators start fine.
The text was updated successfully, but these errors were encountered: