testcontainers
[README]: Contributing new modules
Problem
Hi 👋, in the past few weeks, I've encountered several issues with the GitHub-hosted runners. Due to the increasing number of modules, pulling all the images occupies too much disk space. I've implemented a temporary fix to free up some disk space, but this won't be enough as we add more new modules.
Until we find a suitable fix and implement a mechanism to handle the growing number of modules and image sizes, I prefer not to merge pull requests that involve very simple module configurations. Which can be accomplished with just a few lines using the generic container builder API. If you believe the module is valuable for the community, please consider creating an issue first and discussing it there to avoid unnecessary work on creating a pull request. OC, I will review and try to merge the remaining and outstanding module PRs.
Solution
-
Benefit
-
Alternatives
-
Would you like to help contributing this enhancement?
Yes
Would it be worthwhile to refactor modules so that each image or class of images (e.g. Web/Database/... Servers that might want to share a common interface) has its own repository?
That would mean that exactly one docker image should be created for each image-specific repository, presuming that the same configuration used from multiple implementations in different languages results in an identical container being tested.
We could also describe the image-specific configuration in a common configuration format and use that to generate the language-specific code.
For example, username/password/... is often configured via environment variables, and the specific environment variable names are specific to individual images. However, the code for capturing the username/password is shared between multiple images across multiple languages, which suggests we have too much nearly identical custom-maintained code and are waiting for a refactoring pass to extract the common functionality.
Hi, I think this can help to free some more space for linux workers https://github.com/jlumbroso/free-disk-space
Hi Eddú, we are doing this already:
https://github.com/testcontainers/testcontainers-dotnet/blob/734fb5205492fbf154588e8fd09e4dde47cd3a6e/.github/workflows/cicd.yml#L48-L64
Would it be worthwhile to refactor modules so that each image or class of images (e.g. Web/Database/... Servers that might want to share a common interface) has its own repository?
From past experiences with tc-java, this leads to a lot of operational overhead (e.g. releases), unless we have good automation in place.
Splitting in parallelizing the CI workflow on a per-module or module-sets level can help and it is what we essentially do in tc-java as well.
