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.