Uh oh!
There was an error while loading. Please reload this page.
fix(core): improper reading of .testcontainers.properties - #863
Conversation
alexanderankin
commented
Aug 19, 2025
see if you can make the tests pass? i can take a look to see if i can finish this pr when i am available |
The environment variables were not overridden from the .testcontainers.properties file for ryuk variables. This causes the properties file to never actually be used. This commit detects the environment variable, and if unspecified falls back to the properties file, and if not specifed, defaults to false
laundry-96
commented
Aug 19, 2025
@alexanderankin I fixed it by adding a Optional[bool] defaulted to None, which allows an override for ryuk_disabled and ryuk_privileged programmatically. Sorry for not reading the CONTRIBUTING.md. I didn't see it in the top level directory and didn't see the README.md 😅 I'm on a mac, so the test is set to skipped, but I disabled that and it seems to have passed. I can't be too sure until I see the tests here though. |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@## main #863 +/- ##
=======================================
Coverage ? 82.09% =======================================
Files ? 14 Lines ? 916 Branches ? 148 =======================================
Hits ? 752 Misses ? 128 Partials ? 36 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Removed unused method get_bool_env, as it was replaced with _render_bool Added more tests for proper test coverage for loading variables via testcontainers.properties file
laundry-96
commented
Aug 23, 2025
@alexanderankin Can I get one more run please? I have added some extra test cases and caught some errors myself :) |
laundry-96
commented
Aug 25, 2025
@alexanderankin It seems like the docs build failed due to a connection failure? Mind triggering again? |
alexanderankin
commented
Aug 26, 2025
can you tldr what this code does? im on a work trip right now and just dont have time this week to look at this - i would merge otherwise |
TLDR: Originally when running test containers, you can set variables inside of What was happening originally was that the Function causing this issue: As you can see this would return either True or False. What my change does, is bring this function into the class, and when attempting to access the disabled or privileged class value, it calculates it based on if it was set previously (via code, env, or properties file), and if not then checks the environment, then checks the properties file, then defaults to False Also, I totally understand being busy! I just want to say thank you so much for providing this package from your own time and energy :) |
Uh oh!
There was an error while loading. Please reload this page.
🤖 I have created a release *beep* *boop* --- ## [4.13.0](testcontainers-v4.12.0...testcontainers-v4.13.0) (2025-08-27) ### Features * **azurite:** Enhance connection string generation for network and local access ([#859](#859)) ([b21e5e3](b21e5e3)) * **core:** add enhanced wait strategies ([#855](#855)) ([60d21f8](60d21f8)) * **core:** DockerCompose: support list of env_files ([#847](#847)) ([fe206eb](fe206eb)) ### Bug Fixes * assert-in-get_container_host_ip-before-start ([#862](#862)) ([fc4155e](fc4155e)) * **core:** improper reading of .testcontainers.properties ([#863](#863)) ([350f246](350f246)) * **core:** Make TC_POOLING_INTERVAL/sleep_time a float ([#839](#839)) ([a072f3f](a072f3f)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
fix#864
The environment variables were not overridden from the .testcontainers.properties file for ryuk variables. This causes the properties file to never actually be used. This commit detects the environment variable, and if unspecified falls back to the properties file, and if not specified, defaults to false