feat: add standard org.testcontainers=true label - #969
Conversation
✅ Deploy Preview for testcontainers-rust ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c9ba30fa25
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| labels: BTreeMap::default(), | ||
| labels: { | ||
| let mut l = BTreeMap::new(); | ||
| l.insert("org.testcontainers".to_string(), "true".to_string()); |
There was a problem hiding this comment.
When the optional docker-compose feature is used, DockerCompose::up delegates to the local or containerized Compose client, which runs docker compose up without adding this label to the supplied compose configuration. Thus ordinary Compose services receive only Compose/user labels (the containerized mode labels at most its Docker CLI helper), so docker ps --filter label=org.testcontainers=true will miss workloads that this library started through its documented Compose API.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Good catch on the Compose path. That one is intentionally left out of this PR and here is why.
The change targets the Rust runner's own ContainerRequest::from, which covers every container the library starts directly. The docker-compose feature is a separate route that hands off to the Compose CLI, so labeling there means touching a different code path with its own config handling. I kept this PR small and focused on the runner side, which is what the underlying issue (#926) asks for and where the cleanup gap actually bites.
I am happy to follow up with the Compose service labeling as a second PR if the maintainers want it. For now I would rather not widen the diff of this one.
|
@DDtKey @bergkvist would one of you mind taking a look when you get a chance? I have addressed the bot's P2 note about the Compose path in a reply and kept this PR scoped to the runner's own containers. Tests and fmt and clippy are all green locally. Happy to adjust if you want it handled differently. |
1 participant
Summary
This PR adds the standard
org.testcontainers=truelabel to all containers created by testcontainers-rs, achieving ecosystem consistency with Java and Go implementations.Changes
testcontainers/src/core/containers/request.rs: Added default labelsorg.testcontainers=trueandorg.testcontainers.managed-by=testcontainersinContainerRequest::from()implementation.testcontainers/src/runners/async_runner.rs: Updated testasync_start_should_apply_expected_labelsto expect the neworg.testcontainers=truelabel.Root Cause
Only
org.testcontainers.managed-by=testcontainerswas being added by default. Other language implementations (Java, Go) also addorg.testcontainers=truefor ecosystem consistency. This made it harder to filter/clean up testcontainers across different language implementations using the standard label.Testing
cargo +nightly fmt --all -- --check- PASSEDcargo clippy- PASSEDcargo test --features blocking- 85 passed (1 pre-existing unrelated failure)cargo test --features blocking sync_runner- 35 passedcargo test --features "blocking reusable-containers" --lib- 89 passedcargo test --all-features --lib- 104 passedasync_start_should_apply_expected_labels- PASSED (verifies both labels)Closes #926