Support for bazel?

[Alviner]

Introduction:
Testcontainers-Go is a powerful tool used for writing integration tests in Go, allowing developers to effortlessly manage Docker containers for testing purposes. However, while it seamlessly integrates with traditional Go tests, it lacks native support for tests run under Bazel. This limitation arises due to differences in the execution environment, particularly in the handling of session identifiers. In this discussion, we delve into the challenges posed by this disparity and propose solutions to enable smooth integration of Testcontainers-Go with Bazel.

Challenges:
One of the key challenges in supporting Bazel with Testcontainers-Go is the discrepancy in session identification mechanisms. Testcontainers-Go relies on a session identifier constructed from the parent process ID (pid) and the current working directory (pwd). This session ID ensures proper management of containers and resources across test executions.

However, Bazel operates in a different manner, spawning its own processes independently of the conventional Go test workflow. Consequently, Bazel tests lack the same parent process as Go tests, leading to inconsistencies in session identification. As a result, containers instantiated by Testcontainers-Go within Bazel tests are treated as belonging to distinct sessions, causing issues with resource management and cleanup.

Proposed Solution:
To address this challenge, we propose enhancing Testcontainers-Go to provide native support for Bazel tests. This entails developing a mechanism to generate consistent session identifiers that accommodate the unique execution environment of Bazel.

One potential solution involves augmenting Testcontainers-Go with a custom session identification strategy specifically tailored for Bazel. This strategy could involve leveraging Bazel-provided metadata or environment variables to construct session IDs that remain consistent across test executions.

Furthermore, integrating Testcontainers-Go directly with Bazel's test execution framework could streamline container management and resource cleanup within Bazel tests. This integration would involve developing Bazel-specific rules or extensions that seamlessly orchestrate container lifecycle operations alongside test execution.

To implement this solution, we can introduce a conditional check within Testcontainers-Go to determine whether tests are being executed under Bazel. This check can be based on the presence of Bazel-specific environment variables or other indicators unique to Bazel's execution environment. Upon detecting Bazel as the test runner, Testcontainers-Go would utilize only the current working directory to construct the session identifier.

https://bazel.build/reference/test-encyclopedia

[mdelapenya]

@Alviner thanks for creating this discussion, as Bazel has appeared very frequently in our internal discussions. But we are not Bazel experts, so any support from you or anybody else in the community would be super helpful.

I do agree that having specific support for Bazel would be of interest, but I'd try to abstract as much as possible from adding a possible dependency on any Bazel library. So I'd be up to checking a Bazel environment variable, and if present, apply the Bazel semantics to the sessionId, processId and projectPath.

I think we can use this discussion for a design doc for it. Would you be interested in leading that effort?

[mdelapenya]

Do you think it would be possible to create/define a Bazel rule/macro that reads from bazel info server_pid and pass it to testcontainers-go as an ENV_VAR that affects the sessionID? Something that would automatically do this:

TESTCONTAINERS_SESSION_ID=$(bazel info server_pid) go test ./...

[Alviner]

We've considered this issue, and there are challenges: changing environment variables will reset the entire cache, which is quite critical in Bazel. I'm thinking about using a macro to generate a UUID for each run (or some other value), storing it in a file, and passing the path to this file in the environment variables. It is still unclear how to control the creation of the session identifier. We could apply patches, but we'd prefer to avoid that if possible.

[stevenh]

Could you clarify why different session ids are an issue?

[mdelapenya]

Reviving this, since what it asked for has shipped.

@stevenh, on your question: the concrete failure mode is #2548. One session ID means one ryuk, so under Bazel each target gets its own reaper, and a container shared across targets is reaped by whichever session created it as soon as that session's ryuk drops its last connection, while other targets are still using it. The cost is not the extra ryuk containers, it is the cross-target reaping.

Good news: the override this discussion asked for landed in v0.44.0 (#3051, thanks @jcmfernandes). You can now set the session ID explicitly, either via environment variable:

TESTCONTAINERS_SESSION_ID=my-session go test ./...

or via ~/.testcontainers.properties:

session.id=my-session

Precedence is: TESTCONTAINERS_SESSION_ID wins, then the session.id property, then the computed parent-pid-based default. For Bazel that would be:

bazel test --test_env=TESTCONTAINERS_SESSION_ID=my-workspace-session //...

Note that Bazel sets HOME to $TEST_TMPDIR, so the properties file is not an option there. The environment variable, explicitly propagated, is the way.

@Alviner, on your cache concern: the session ID does not need to be unique per run, it needs to be stable across the set of targets you want to share a reaper. So a constant value derived from the workspace, rather than a freshly generated UUID, should keep the value identical between runs and avoid the churn you were worried about. Does that hold in your setup, or does Bazel invalidate on something beyond the env value itself? That is the part I cannot speak to with any authority.

Two caveats worth knowing before you wire this up:

1. A constant session ID means concurrent independent runs on the same daemon share one reaper and will reap each other's containers. Fine for a single dev machine or a single CI job, risky on a shared daemon.
2. The config is read once per process, so the variable has to be set before the first container is created.

The value ends up in the reaper's container name, so it has to be usable there. I have #3849 open to validate that when the configuration is read, instead of failing later at container creation, and to document the whole thing in test_session_semantics.md, including the Bazel section above.

Given that, I think the remaining scope here is much smaller than the original proposal: no Bazel dependency and no auto-detection of Bazel env vars, just documenting the pattern. If someone from the Bazel side wants to contribute a rule or macro that sets this, that would be a welcome addition to the docs. Would that close the gap for you both, or is there a case where a fixed session ID is still not enough?