Force Clean Containers on build before start

[mubeda]

.WithCleanUp(true) works well if you don't have any crash on your application. But after a crash you cannot build the container again. For Postgresql you get this exception ("Message = "An item with the same key has already been added. Key: 5432/tcp"). Basically you need to go to the docker app and remove the container manually.
It will be really nice that everytime you build a container with the WithCleanUp(true) it forces the delete of the container if it already exist.

Thanks!

[HofmeisterAn]

@mubeda There is already a mechanism to delete remaining containers at the end. See: https://github.com/HofmeisterAn/dotnet-testcontainers/blob/d2469b35d8f7496411ac5ca8d3486b4ab65b8957/src/DotNet.Testcontainers/Clients/TestcontainersClient.cs#L56-L57

Either the event is not triggered or finished in time. The total execution time of all finalizers is limited in .NET Framework. I'm aware that this implementation has some disadvantages. However, it is simple and has always worked in my use cases.

• Which framework do you use?
• Do you always use the same container name?
• Can you test if the event is fired at all and provide some more information?

---

In addition to that. I guess you are mapping the host port 5432 to the container port 5432. It's recommended to use a random host port and assign that to the default container port. This is the default behavior and good practice, see: https://github.com/HofmeisterAn/dotnet-testcontainers/blob/4acf978e59578c1b99590eafef74edefb10791ff/src/DotNet.Testcontainers/Containers/Configurations/Abstractions/TestcontainerDatabaseConfiguration.cs#L10

It will prevent mapping the same host port multiple times (of course, it's just a workaround and not a proper fix).

[mubeda]

Hey Andre!
Thank you for the response. I use .net core 3.1, i always use use the same container name and fixed ports, i am trying to implement automatic test cases for all dbms i support in my application.
. This problem happens to me once when i stopped the execution of the process, then the code of PurgeOrphanedContainers is never executed. Basically i had to go to docker and manually delete the running instance. So i was courious if this Purge can be done by instance name on app startup. Feel free to close this ticked if you thing it's not needed.

[HofmeisterAn]

If you kill the process (includes canceling tests), the event is not triggered at all. This is another drawback of the implementation I was talking about. The official implementation uses an independent container as ResourceReaper to kill orphaned containers. This would be a great and very useful feature.

If someone starts with the implementation I am happy to jump in. I just can't bring myself to do it at the moment, because I don't need it urgently.

[HofmeisterAn]

Containers with status exited will be removed in the next test cycle (#369).

[savalik]

I'm afraid it's not helpful for this issue - because contrainers remain online.

[HofmeisterAn]

I'm afraid it's not helpful for this issue - because contrainers remain online.

What status do the containers have? The implementation will only remove containers with status exited. It won't remove running containers from previous runs.

[HofmeisterAn]

Resource Reaper added for Linux containers in 1.6.0-beta.2085, see #413.