feat: added firebase module #2954

xytis · 2025-01-30T18:46:12Z

What does this PR do?

This module allows running firebase emulator as a testcontainer.

It does currently depend on a forked docker image, residing under my ownership. There is no official firebase emulator docker image to my knowledge.

Why is it important?

We use firebase, thought someone else might be using firebase too.

netlify · 2025-01-30T18:46:30Z

✅ Deploy Preview for testcontainers-go ready!

Name	Link
🔨 Latest commit	`fd6035e`
🔍 Latest deploy log	https://app.netlify.com/sites/testcontainers-go/deploys/680b7dcc6dca280008bd401e
😎 Deploy Preview	https://deploy-preview-2954--testcontainers-go.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

stevenh

Thanks for the PR, I've done a initial pass. The majority of comments center around bringing it inline with the latest template for modules in terms of style and correct behaviour e.g. handling non nil container with error.

modules/firebase/examples_test.go

modules/firebase/anchor_test.go

stevenh · 2025-01-30T19:06:53Z

modules/firebase/firebase.go

+// WithRoot sets the directory which is copied to the destination container as firebase root
+func WithRoot(rootPath string) testcontainers.CustomizeRequestOption {
+	return func(req *testcontainers.GenericContainerRequest) error {
+		if !strings.HasSuffix(rootPath, "/firebase") {


question: Could you clarify why this requirement is needed?

This has been an issue a year ago. Mounting did not correctly work at that time, and if the source directory did not match the destination directory, mounting would nest the directory instead of mapping it directly.

I see that the issue has been fixed, removing.

Ah, my bad. The issue still exits. I wrote a failing test to exhibit the issue.

Is there something incorrect with the way I copy over the configuration?

Also, I don't think that volume mount would work in this case, because firebase emulator creates a lot of trash data in the root catalog, which in some cases can even make testing flaky (especially if using DATA_DIRECTORY as a fixture).

I'll try to find some time to look. I had a some in progress work to fix up the copy behaviour which was odd.

If you have a test to exercise this that, would help alongside a description of the desired behaviour and what you're seeing instead.

modules/firebase/firebase.go

modules/firebase/firebase_test.go

stevenh · 2025-01-30T19:17:14Z

modules/firebase/ports.go

+	return fmt.Sprintf("%s:%s", host, port.Port()), nil
+}
+
+func (c *FirebaseContainer) UIConnectionString(ctx context.Context) (string, error) {


question: seems like lots of additional API surface area instead of just exposing ConnectionString, thoughts?

If not then we'd need comments for all the methods.

This one is a bit more tricky.

I would love to change all of these methods, and figure out a better way to configure the launched container.

Currently I ship a catalog which contains static predefined configuration for the emulator. These methods happen to match the port numbers defined in the said file.

But, in the tests that we use, we provide a completely different setup (because we don't want to boot the full emulation suite), and we have to match the port numbers in our config so that all of this works.

So a question from my side would be:
Is there a way to generate file based config during container setup? To my knowledge firebase emulator does not allow passing those values as environment variables.

I think, ideal use example would be this:

firebaseContainer, err := firebase.Run(ctx, "ghcr.io/u-health/docker-firebase-emulator:13.29.2", firebase.WithUI(), firebase.WithFirestore(), firebase.WithCache(), )

And then, helper methods XXXConnectionString would actually return meaningful errors if the emulator part was not launched.

Is there a way to generate file based config during container setup?

@xytis you can take a look at the redpanda module, where there is a Go template the module is using to build the configuration file.

After some testing on my side, I remembered why I shipped the config as a directory in the first place.

Default (and probably expected) use case for firebase projects, is to run firebase init and then use the scaffolded configuration to interact with the dependencies.

In the following commit, I've changed the behaviour of this module. It now attempts to understand the emulator configuration of your project and then boots the containerised emulator with that info.

At least in my use case, that makes sense, and when I launch the tests, I use the same project-wide config for all of them.

stevenh · 2025-01-30T19:17:32Z

modules/firebase/ports.go

+func (c *FirebaseContainer) connectionString(ctx context.Context, portName nat.Port) (string, error) {
+	host, err := c.Host(ctx)
+	if err != nil {
+		return "", err


suggestion: wrap the error so the user knows the cause, more below.

stevenh

Thanks for the updates

.github/workflows/ci.yml

.vscode/.testcontainers-go.code-workspace

modules/firebase/config.go

modules/firebase/firebase_test.go

sonar-project.properties

mdelapenya

I added a few minor comments, we are in the good way.

Thanks for your contribution

mdelapenya · 2025-01-31T09:05:18Z

docs/modules/firebase.md

+
+### Container Methods
+
+The Firebase container exposes the following methods:


docs: we probably need to append here the new methods the container expose

@xytis let's not forget adding here ConnectionString 🙏

docs/modules/firebase.md

.github/workflows/ci.yml

docs/modules/firebase.md

modules/firebase/failure/.firebaserc

modules/firebase/firebase.go

mdelapenya · 2025-02-03T12:28:47Z

docs/modules/firebase.md

+E.g. `Run(context.Background(), "ghcr.io/u-health/docker-firebase-emulator:13.29.2")`.
+
+{% include "../features/common_functional_options.md" %}
+


docsd: we need to add here all the functional options for the module.

@xytis let's not forget adding the WithData option here 🙏

docs/modules/firebase.md

mdelapenya · 2025-03-13T11:43:35Z

One question: reading the README in the docker image:

Supports GRPC for firestore and pub/sub.

What are the differences with the existing Google Cloud emulators? We do have them under the gcloud module, and we currently plan to follow the same package structure as in the upcoming azure module (see #3008). Do you think this firebase has enough entity to be a separate module, or should it live alongside the other gcloud modules?

xytis · 2025-03-13T11:47:31Z

Last time I checked, gcloud emulators did not provide the full suite of emulations. I will check this again and come back to you.

mdelapenya · 2025-04-03T05:05:50Z

@xytis we merged the layout revamp in the gcloud module. Do you think we can move this there?

xytis · 2025-04-03T07:31:07Z

Hey,

unfortunately not.

gcloud emulators do not include the following:

firebase auth
firebase storage (which is an access control layer on top of gcloud storage)
firebase pubsub (again, a layer on top, with some helpers)

I am not certain about the rest.

mdelapenya · 2025-04-03T07:57:30Z

gcloud emulators do not include the following:

but we're going to use the ghcr.io/u-health/docker-firebase-emulator:13.29.2 Docker image, which has them. So I'd like to know if it's "semantically" correct to locate this code under the gcloud module, so it's distributed with all GCP services, or if on the contrary, it makes more sense to have it as a separate module.

I do not have an opinion on this, so as the author of the image, please feel free to be prescriptive about it. 🙏

xytis · 2025-04-03T08:01:41Z

Well, if I was searching for "firebase" emulators, I would not look under "gcloud". Mostly because the tooling and the documentation (both provided by google) are very different for these two products.

I think, having these two separate makes more sense as long as there are development differences between running gcloud and firebase executables.

mdelapenya · 2025-04-03T08:19:08Z

LGTM then to continue as a separate module, thanks! 🙏

I can help you out rebasing this PR resolving the conflicts before moving on with the review

xytis · 2025-04-03T09:59:18Z

Please do, I am a bit occupied at the moment.

Thanks.

* main: (91 commits) chore(deps): bump github/codeql-action from 3.28.13 to 3.28.15 (testcontainers#3097) chore(deps): bump golang.org/x/crypto from 0.31.0 to 0.37.0 (testcontainers#3098) feat(aerospike): add Aerospike module (testcontainers#3094) security(compose): upgrade github.com/docker/compose/v2 to fix security vulnerability (testcontainers#3095) feat: add more functional options to the modules API (testcontainers#3070) chore(deps): bump golang.org/x/net in /modules/arangodb (testcontainers#3087) feat: add arangodb module (testcontainers#3083) chore(deps): bump actions/upload-artifact from 4.6.0 to 4.6.2 (testcontainers#3086) chore(deps): bump SonarSource/sonarqube-scan-action from 5.0.0 to 5.1.0 (testcontainers#3085) feat: add socat container (testcontainers#3071) fix(mssql): reduce flakiness in tests (testcontainers#3084) chore: bump golangci-lint to v2 (testcontainers#3082) chore(gcloud): deprecate old gcp containers, creating subpackages for them (testcontainers#3063) fix(mongodb): replica set initialization & connection handling (testcontainers#2984) chore(deps): bump docker/setup-docker-action from 4.2.0 to 4.3.0 (testcontainers#3077) chore(deps): bump github/codeql-action from 3.28.12 to 3.28.13 (testcontainers#3078) chore(deps): bump tj-actions/changed-files from 45.0.4 to 46.0.3 (testcontainers#3076) docs: add dependabot configuration (testcontainers#3074) chore(deps): replace `golang.org/x/exp/slices` with stdlib (testcontainers#3075) fix(dind): use docker image load (testcontainers#3073) ...

mdelapenya · 2025-04-14T09:59:52Z

@xytis I cannot push to your branch because this PR was submitted from your main branch 😞

I've pushed it to my origin so that you can check and pick up the commits: https://github.com/testcontainers/testcontainers-go/compare/main...mdelapenya:testcontainers-go:firebase-module?expand=1

I still have doubts about the WithData option, probably as a result of being this one my first interaction with Firebase. Could you help me out in understanding its motivation? I'd need some tests in the code to verify it works as expected.

Sync with upstream

xytis · 2025-04-14T12:05:47Z

@mdelapenya merged your changes.

I was forced to use WithData because Firebase emulators expect a specific directory structure and files to exist in the "project root".

I toyed with providing structured config, but I am not using that in my own tests. It was easier to bootstrap a directory with a specific catalog structure, and I just clone that into the container.

Rough docs on this are here: https://firebase.google.com/docs/emulator-suite/install_and_configure

mdelapenya · 2025-04-22T15:08:12Z

@xytis lint is complaining. Could you run make lint from the firebase module dir? 🙏

mdelapenya · 2025-04-22T15:12:58Z

modules/firebase/go.mod

+
+go 1.23.0
+
+require (


suggestion: just before submitting the changes, run go mod tidy from the module dir to make sure all dependencies are in sync with the core. Else we'll receive an extra PR from dependabot 😅

go mod tidy returned no changes. Was this expected?

Probably no changes are missing. I just want to double check we are not missing recent updates in the main branch.

mdelapenya · 2025-04-23T07:45:54Z

@xytis for some reason, the lint still fails:

  Error: modules/firebase/modules/firebase/firebase_test.go:13:1: File is not properly formatted (gci)
  
  ^
  Error: modules/firebase/modules/firebase/options.go:7:1: File is not properly formatted (gofumpt)

Once fixed, and the docs are updated (see #2954 (comment) and #2954 (comment)), I think we are good to merge.

mdelapenya

I'm approving this PR already, although there are some comments to be addressed before we merge it:

documentation adding the WithData options and the ConnectionString container method
Steven's suggestion regarding wrapping errors.

Other than that, LGTM, thanks so much for your patience during the review, we do appreciate your hard work with Testcontainers and the Firebase emulator. 🙇

mdelapenya · 2025-04-23T07:48:23Z

modules/firebase/ports.go

+func (c *Container) ConnectionString(ctx context.Context, portName nat.Port) (string, error) {
+	host, err := c.Host(ctx)
+	if err != nil {
+		return "", err


Suggested change

return "", err

return "", fmt.Errorf("host: %w", err)

@xytis friendly ping! 🙏

I'll get to this once I have some time :)

I'm cutting a release today. Do you mind if, as this PR was sent from your main branch and I cannot contribute to it, I close this PR and submit another PR with your commits and my suggestions on top? Then I can incorporate this new module in today's release

Oh, sure. Do as you wish :)

Honestly, I am fine if you took the code and rebased into whatever location you need it to be :)

Just note that the issue which was blocking this module is still here:

I can not copy directories into container, if the source dir name and the dest dir name are not matching.

There is a test/example for that, but I placed an inverse condition for some reason.

I'll revert it now, so it would be clear why this is lagging for so long.

Indeed, that limitation exists at the moment. My question now would be: why would the users of the firebase module like to provide a wrong dir name? I can see two types of users:

developers of the firebase emulator, who would need different failure modes while developing it

developers using the emulator, who would not need that particular failure mode.

I guess developers in group 1 would love to have multiple root dirs with different use cases. As a workaround I can think of a previous step that copies those dirs to a (t.TempDir() + "/firebase"), and then copy that temporary dir to the container. We can add now an issue to testcontainers to resolve the issue as soon as possible and remove that workaround right after it's released.

Of course, as a firebase noob, I'm probably missing other concerns you may have clear. Please let me know what you think about this 🙏

The only reason why someone would have issues with directory name is when you have different setups for different tests.

In that case, the workaround seems to be a good solution.

Let's do this: let the functional option do that automatically, storing the temp root dir in the container so that we add a new Terminate function that: 1) removes the temp dir, and 2) calls container.Terminate. Please honor the Terminate signature

@stevenh @xytis thoughts?

modules/firebase/ports.go

Co-authored-by: Manuel de la Peña <[email protected]>

…ot cause

stevenh

Just a quick pass as I'm busy today.

stevenh · 2025-04-25T09:06:46Z

modules/firebase/config.go

+		Port uint16 `json:"port,omitempty"`
+	} `json:"tasks,omitempty"`
+}
+type partialFirebaseConfig struct {


nit: add a blank line between types, suspect it will fail linting without.

stevenh · 2025-04-25T09:08:46Z

modules/firebase/examples_test.go

+	ctx := context.Background()
+
+	firebaseContainer, err := firebase.Run(ctx, "ghcr.io/u-health/docker-firebase-emulator:13.29.2",
+		firebase.WithRoot(filepath.Join("testdata", "firebase")),


info: using literal "testdata/firebase" works fine on all platforms as even though windows uses \ it also accepts /.

stevenh · 2025-04-25T09:12:01Z

modules/firebase/firebase.go

+			host := hostF.String()
+			if host != "0.0.0.0" {
+				return nil, fmt.Errorf("config specified %s emulator host on non public ip: %s", name, host)
+			}


question: this seems to limit host to 0.0.0.0, if so why have the field? that said I'm not sure this check is needed, do you have an example of why it is?

If the emulator config (which we found in the user provided directory) uses host value other than "0.0.0.0", it will launch that emulator listening on docker internal IP. So no traffic will be able to enter the emulator, leaving the users very much confused.

stevenh · 2025-04-25T09:29:55Z

modules/firebase/firebase.go

+		portF := emulator.FieldByName("Port")
+		websocketPortF := emulator.FieldByName("WebsocketPort")
+
+		if hostF != (reflect.Value{}) && !hostF.IsZero() {


suggestion: use IsValid to simplify test, more below

Suggested change

if hostF != (reflect.Value{}) && !hostF.IsZero() {

if hostF.isValid() && !hostF.IsZero() {

stevenh · 2025-04-25T09:30:24Z

modules/firebase/firebase.go

+		if emulator.Kind() != reflect.Struct {
+			continue
+		}
+		name := v.Type().Field(i).Name


suggestion: extract type lookup out of the loop as its invariant.

stevenh · 2025-04-25T09:34:18Z

modules/firebase/firebase.go

+	bytes, err := io.ReadAll(cfg)
+	if err != nil {
+		return nil, fmt.Errorf("read firebase.json: %w", err)
+	}
+
+	var parsed partialFirebaseConfig
+	if err := json.Unmarshal(bytes, &parsed); err != nil {
+		return nil, fmt.Errorf("parse firebase.json: %w", err)
+	}


suggestion: use a stream reader to be more memory efficient, its a small benefit but good practice.

stevenh · 2025-04-25T09:35:08Z

modules/firebase/firebase.go

+	if err != nil {
+		return nil, fmt.Errorf("gather ports: %w", err)
+	}
+	req.ExposedPorts = expectedExposedPorts


question: should we wait for all ports instead of the fragile log wait?

I had the same idea, but now I don't remember why I reverted back to logs.

modules/firebase/ports.go

stevenh · 2025-04-25T09:42:25Z

modules/firebase/firebase_test.go

+	// What would be a solution here? Previously I just added a check that the root must
+	// end in "/firebase"... I could do the same.
+	testcontainers.CleanupContainer(t, ctr)
+	require.NoError(t, err)


bug: this should fail, as I understand it this is down to how our copy works or doesn't. I have an unfinished PR in this area here.

I would change this to check for err as expected and mark the test as skip for now.

Co-authored-by: Steven Hartland <[email protected]>

mdelapenya · 2025-05-07T17:10:20Z

For reference, Google released an official image: firebase/firebase-tools#1644 (comment)

xytis · 2025-05-07T17:28:30Z

Ah, cool. I'll adapt to that container once I have some free time.

mdelapenya · 2025-05-08T08:12:12Z

Fantastic! thanks for your time @xytis , we appreciate it!

feat: added firebase module

29b1bba

xytis requested a review from a team as a code owner January 30, 2025 18:46

chore: bump default container version

6a88123

stevenh requested changes Jan 30, 2025

View reviewed changes

stevenh requested changes Jan 31, 2025

View reviewed changes

fix: rewrote the module based on comments

4105b0a

xytis force-pushed the main branch from aef1039 to 4105b0a Compare February 2, 2025 08:40

fix: another pass at comments

cc2bfa4

xytis force-pushed the main branch from 7404470 to cc2bfa4 Compare February 2, 2025 09:37

fix: ports are uint

7c24032

mdelapenya reviewed Feb 3, 2025

View reviewed changes

mdelapenya reviewed Mar 13, 2025

View reviewed changes

docs/modules/firebase.md Show resolved Hide resolved

mdelapenya mentioned this pull request Mar 13, 2025

Please provide official docker image firebase/firebase-tools#1644

Closed

mdelapenya added 8 commits April 14, 2025 10:46

chore: bump testcontainers-go to latest

bc33438

chore: move to testdata

1a72008

chore: use custom error when root is needed

c2b8e2b

fix: handle error in test

ba0bdc0

chore: use new functional options

80298e5

fix: no need to pass labels, as they are added in the core

4e271db

chore: proper error message

34409eb

mdelapenya added 4 commits April 14, 2025 11:36

chore: move options to its file

fb2c0aa

chore: simplify concat

88cb16d

chore: add whilelines to separate concerns

aa4c29c

docs: document the new options

458cc7c

merge: pull request #1 from mdelapenya/firebase-module

ae27c74

Sync with upstream

mdelapenya reviewed Apr 22, 2025

View reviewed changes

fix: lint pass

ae49941

fix: another lint pass

cff37d9

mdelapenya previously approved these changes Apr 23, 2025

View reviewed changes

Update modules/firebase/ports.go

9fe4988

Co-authored-by: Manuel de la Peña <[email protected]>

xytis dismissed mdelapenya’s stale review via 9fe4988 April 25, 2025 08:07

xytis and others added 3 commits April 25, 2025 11:07

Update modules/firebase/ports.go

3ed1839

Co-authored-by: Manuel de la Peña <[email protected]>

Merge branch 'main' into main

d578817

chore: reverted example test to failing state, so we could fix the ro…

72c1f45

…ot cause

stevenh requested changes Apr 25, 2025

View reviewed changes

Update modules/firebase/ports.go

fd6035e

Co-authored-by: Steven Hartland <[email protected]>


		### Container Methods

		The Firebase container exposes the following methods:

		E.g. `Run(context.Background(), "ghcr.io/u-health/docker-firebase-emulator:13.29.2")`.

		{% include "../features/common_functional_options.md" %}

	if hostF != (reflect.Value{}) && !hostF.IsZero() {
	if hostF.isValid() && !hostF.IsZero() {


		go 1.23.0

		require (

Uh oh!

feat: added firebase module #2954

Are you sure you want to change the base?

feat: added firebase module #2954

Uh oh!

Conversation

xytis commented Jan 30, 2025

What does this PR do?

Why is it important?

Uh oh!

netlify bot commented Jan 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Deploy Preview for testcontainers-go ready!

Uh oh!

stevenh left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

stevenh left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

mdelapenya left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mdelapenya Apr 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

mdelapenya commented Mar 13, 2025

Uh oh!

xytis commented Mar 13, 2025

Uh oh!

mdelapenya commented Apr 3, 2025

Uh oh!

netlify bot commented Jan 30, 2025 •

edited

Loading

mdelapenya Apr 22, 2025 •

edited

Loading

mdelapenya commented Apr 3, 2025 •

edited

Loading

xytis commented Apr 3, 2025 •

edited

Loading