You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Given that, especially in the case of Azurite, to update the Storage packages from NuGet in consuming projects means that you have to match the corresponding API version on the container, this is very prohibitive.
The classes are also sealed for some reason. There's no way to override this without duplicating the class in your own project.
Solution
Provide an option to configure the Image that's used for these containers, whilst retaining the benefits of the rest of the module.
This could be easily achieved by allowing either a configuration object to be passed in or, at the very least, allow the image name to be overridden within the constructor.
publicsealedclassAzuriteBuilder:ContainerBuilder<AzuriteBuilder,AzuriteContainer,AzuriteConfiguration>{publicreadonlystringAzuriteImage="mcr.microsoft.com/azure-storage/azurite:3.28.0";// .../// <summary>/// Initializes a new instance of the <see cref="AzuriteBuilder" /> class./// </summary>publicAzuriteBuilder(string?imageName=default):this(newAzuriteConfiguration()){AzureiteImage=imageName??AzuriteImage;DockerResourceConfiguration=Init().DockerResourceConfiguration;}
I'm happy to go through and implement this where necessary, but this may be an intentional restriction for reasons I can't understand?
Benefit
Allows more flexibility for tests without restricting projects to specific versions of images.
I understand that this might be done for major changes, but obviously it doesn't have to be a fully supported option when using these builders.
Alternatives
Unseal the classes to allow overrides to be manually performed.
Would you like to help contributing this enhancement?
Yes
The text was updated successfully, but these errors were encountered:
There's no way to override this without duplicating the class in your own project.
That's not right. Actually, we encourage and recommend overriding and pinning the image version in our best practices. Every container builder supports the WithImage(string) API, which lets you set the exact image and version used:
_ = new AzuriteBuilder().WithImage("mcr.microsoft.com/azure-storage/azurite:3.32.0").Build();
There might be cases where a new image version breaks an existing module configuration, like we recently had with MSSQL. When that happens, we update the module configuration accordingly to support multiple versions. Another good example is our MongoDB module that supports multiple major versions too.
Problem
Image Names are currently constants within the Builders, example https://github.com/testcontainers/testcontainers-dotnet/blob/1d32bc86e902f4684c8b348dbb82a0f44a579c0e/src/Testcontainers.Azurite/AzuriteBuilder.cs#L7C5-L7C89
Given that, especially in the case of Azurite, to update the Storage packages from NuGet in consuming projects means that you have to match the corresponding API version on the container, this is very prohibitive.
The classes are also
sealed
for some reason. There's no way to override this without duplicating the class in your own project.Solution
Provide an option to configure the Image that's used for these containers, whilst retaining the benefits of the rest of the module.
This could be easily achieved by allowing either a configuration object to be passed in or, at the very least, allow the image name to be overridden within the constructor.
I'm happy to go through and implement this where necessary, but this may be an intentional restriction for reasons I can't understand?
Benefit
Allows more flexibility for tests without restricting projects to specific versions of images.
I understand that this might be done for major changes, but obviously it doesn't have to be a fully supported option when using these builders.
Alternatives
Unseal the classes to allow overrides to be manually performed.
Would you like to help contributing this enhancement?
Yes
The text was updated successfully, but these errors were encountered: