Feature/firebase emulator config switch

[jfbenckhuijsen]

No description provided.

[jfbenckhuijsen]

@loicmathieu

Ok, quite a bit of work so far:

• The code for the underlying FirebaseContainerEmulator has seen quite some changes. Most of them are to

  1. support some additional features (like enable debugging, pipe logging from the container to the host, additional flags to setup the emulator etc
  2. Added a Builder API to create the configuration, which results in quite a bit of cleaner code than before, especially when translating between the Quarkus config and the emulator config
  3. The emulator classes are pulled to a separate package
  4. The loading logic for a custom firebase.json file has been greatly expanded, meaning the code will detect the majority of the settings there and use that. I.e. if you create a new firebase project and use your firebase.json file (with some minimal changes) you're good to go and can easily switch between the normal emulator (running via terminal or whatever) and the dockerized version.

• ConfigRoot issues should be resolved now. Everything is neatly pulled into a "q.g.c.devserices.*" config root

• The creation code should automatically detect a firebase.json file in the root of the project (i.e. the current working directory for tests), so just including the module should be enough to get this running for any firebase project (the docs have been updated accordingly).

SCRATCH THIS BELOW, IM AN IDIOT ;)

The only issue I'm debugging right now (hence marked the branch as work in progress) is that the firebase-admin tests are failing. The issue is that the io.quarkiverse.googlecloudservices.firebase.admin.runtime.authentication.http.FirebaseSecurityAuthMechanism in the branch is not detected as a CDI bean for some reason. Haven't been able to figure out why. Injecting it from a test inside the module itself works fine, but for some reason I can't inject it from the firebase-auth integration test module

[jfbenckhuijsen]

@loicmathieu question w.r.t. the currently failing build. Cause of that is that the tests try to validate that a function is running, which requires the packages needed for that function are installed (i.e. run npm install). As this hasn't been done in the build, it fails. Currently see the following options to resolve this:

1. Disable the unit test fully. Functions work, but we won't see any regressions
2. Run a npm install before running the maven build to get those dependencies installed
3. Move those tests to the integration tests and only run them manually.
4. ...?

any preference?