[Enhancement]: Force user provided image name/tag when creating Builder

[digital88]

Problem

As per discussion: https://github.com/testcontainers/testcontainers-dotnet/discussions/1470 Related: https://github.com/testcontainers/testcontainers-dotnet/discussions/1407

By default, Builders use hardcoded default image versions. Those versions deprecate quite rapidly, so many other TC implementations opt to force user to provide desiriable image tag explicitly when creating Builder instance.

Solution

Mark current parameterless constructor as [Obsolete]. Introduce new Builder(DockerImage) constructor. Rewrite old constructor implementation to call this new constructor with default hardcoded image for compatibility.

Benefit

No need to support outdated/insecure versions of docker images.

Alternatives

Continue to support old images indefinitely.

Would you like to help contributing this enhancement?

Yes

[HofmeisterAn]

Thanks for creating this issue, it is a great first step in addressing the topic.

As you mentioned, other language implementations already follow this approach, so aligning .NET makes perfect sense. It also helps stabilize test environments through version pinning. Although, I am a little concerned some developers might misunderstand the decision or find it harder to get started with Testcontainers.

Here are some initial thoughts on what we need to cover in this issue (there could be more):

• Mark the default constructor as obsolete (with a message that points to the expected default repository).
• Each module should include XML documentation that references the expected default repository.
• For our module tests, we could use a shared Dockerfile that contains all required images, and then map them to our tests.
  • That way, we could use Dependabot to keep images updated, similar to how Testcontainers for Node does it.
  • We should discuss whether this is the best approach for us, or if there is a better workflow.

WDYT?

[digital88]

Good points. I too like TC for Node approach with standalone dockerfile + dependabot.

I think we also need to define strategy what to do if the new docker image for module breaks compatibility, like what happened with kafka recently. For how long should previous version be supported or should it be supported at all?

[HofmeisterAn]

For how long should previous version be supported or should it be supported at all?

For now, I'd stick with the proposal that's part of the discussion. We should also add the information to the module documentation to make it clearer and more concrete.

[HofmeisterAn]

TODOs

• [ ] Fix https://github.com/testcontainers/testcontainers-dotnet/issues/1598.
• [ ] Add workflow to update the Dockerfile (using Dependabot).
• [x] Prepare a draft PR that updates the docs.
• [ ] Prepare a draft PR that updates the Testcontainers module catalog.
• [ ] Update the examples after the 4.10.0 release.

[digital88]

• Prepare a draft PR that updates the Testcontainers module catalog.

Is this one up to do still or you are already working on it? I can start this if it's not yet started.

[HofmeisterAn]

• Prepare a draft PR that updates the Testcontainers module catalog.

Is this one up to do still or you are already working on it? I can start this if it's not yet started.

No, I'm not working on that. I plan to look at the Xunit module and support configuring the container image platform. Once that's done, I'll publish a new release. Preparing the module catalog would be great 👍.