feat(termination)!: make container termination timeout configurable

[moogacs]

What does this PR do?

• extend Terminate() method with optional configuration for timeout configuration.
• moved the terminationOptions under container to give the ability to make timeout, etc configurable via a functional option.
• moved cleaning up under Terminate() function.

Why is it important?

• Terminate() became broken with latest release version with latest release 0.34.0 Terminate() require handle for errors "is already in progress"
• this is CleanupContainer method signature and to use it in down streams that will require many refactors because it expects testing.TB

func CleanupContainer(tb testing.TB, ctr Container, options ...TerminateOption) {

so with this change it will give the ability to configure the timeout and move the cleanup logic under termination

Related issues

• Closes [Bug]: response from daemon: removal of container x is already in progress on calling Terminate() #2917

a unit test added and shall be tested with all the existed pipelines

[netlify]

✅ Deploy Preview for testcontainers-go ready!

Name	Link
🔨 Latest commit	31203a9
🔍 Latest deploy log	https://app.netlify.com/sites/testcontainers-go/deploys/676bf2d0a34d940008eb276b
😎 Deploy Preview	https://deploy-preview-2926--testcontainers-go.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[stevenh]

Thanks for PR, seems like a good idea, unfortunately this approach doesn't work with an interface design, see comments for details.

[stevenh]

bug: This ties the container implementation to the concrete DockerContainer type, which would prevent other types implementing Container for example the incoming ollama change.

We could maintain the dedicated type but export it and the fields, which could then be embedded in others.

The challenge with that is you can't rely on the interface to ensure an implementation is complete so it may be better to bite the bullet and make them concrete options @mdelapenya thoughts?

[moogacs]

yeah, i had similar feeling, but wasn't sure if shall i introduce a separate type, when i was opening this PR i tried to make as minimal breaking change but seems it has to be. open for suggestions

i like the idea of maintain the dedicated type but export it and the fields

[stevenh]

I initially thought the dedicated type would work, but that wont ensure that all Container implementations support the options, which I'm not a fan of as a consumer would be left wondering why their options didn't work.

[moogacs]

the other thought i had before i come to this was introducing it in the ContainerRequest and add getter in the container interface

[stevenh]

I thought about setters too, but I think that would make it much harder to discover for users.

I can't think of any perfect solution ATM, something mull over.

[moogacs]

i have made a change and revert it to make sure it uses terminateOptions instead of the dependency on DockerContainer type.

also added more test to show case the usage and the changes of configuration

defaults of volumes is nil, timeout is 10 and context is passed already on Terminate() , lmk wdyt ?

[stevenh]

Thanks for fleshing out what this looks like, I've done a review on how it stands and will discuss with @mdelapenya in the new year the pros and cons of functional options vs require args.

[moogacs]

@stevenh thanks for feedback, i have address the comments. looking forward, Happy new year 😊

[stevenh]

Sorry to be a pain, but looking at what you've done with this, we should actually make the fields private with methods to avoid any ambiguity as to their use by other types, see suggestion in cleanup.go.