[Enhancement]: Environment Variables for Named Image Paths

[jzabroski]

Problem

If an image is not available, e.g. due to a bug, the simplest workaround recommended today is to add .WithImage("docker-registry-url-path-to-image") to the code.

Solution

Ideally, image builders would have names, and those names would be able to specify via environment variable an alternative url to the ones hardcoded in TestContainers packages.

Benefit

C# code is not directly edited, and changes can be flipped via command line environment variables, such as in Runners (GitHub Actions, AZP, etc). This would also facilitate other user stories, such as using The GitHub Actions matrix strategy to run the job with multiple images.

Alternatives

1. Lots of commits to my GitHub repository's /src/ or /tests/ folders that have nothing to do with the actual purpose of the repository, or than to alter dependencies.
2. Implement my own environment variables for the images I care about, and do:

   var sqlServerImage = Environment.GetEnvironmentVariable("FM_TestContainers_SqlServer_RemoteUri");
   if (sqlServerImage != null)
     builder = builder.WithImage(sqlServerImage);

Would you like to help contributing this enhancement?

No

[HofmeisterAn]

Thanks for creating the issue. Interesting idea. Are you thinking of a specific API that configures an environment variable for the builder to read from, for example:

WithImageFromEnvVar("<env_var_name>")

Or would you prefer a default environment variable for each module, such as:

TESTCONTAINERS_MSSQL_IMAGE

so that every instance of MsSqlBuilder automatically uses the configured image?

Maybe we could combine this with an API that reads the value from different sources.

[jzabroski]

TESTCONTAINERS_MSSQL_IMAGE

I was thinking the naming convention would match the package naming convention, converting periods to underscores and appending _IMAGE. In theory if you used something like Daniel Cazzulino's (kzu) ThisAssembly.Project https://www.nuget.org/packages/ThisAssembly.Project

<PropertyGroup>
    
    <ContainerImageUriEnvironmentVariable>TESTCONTAINERS_MSSQL_IMAGE</ContainerImageUriEnvironmentVariable>
  </PropertyGroup>
  <ItemGroup>
    
    <ProjectProperty Include="ContainerImageUriEnvironmentVariable" Comment="Each TestContainers assembly has a uniquely named environment variable for overriding the image." />
  </ItemGroup>

The benefit of using ThisAssembly is it automatically parallelizes the unit of computation by managing many partial classes, one for each contstant, although it might be overkill for just one. However, you can also copy-paste the same builder code everywhere.

The other benefit I considered is that, if Microsoft Docker ever gets its stuff together and we get Windows SQL Server containers, a GitHub Actions strategy matrix could provide a different environment variable to each one.