Is there a way to bind an already running container to a StartedTestContainer?

[redjolr]

Let's suppose that I am have run some container manually, without using testcontainers.
Is there a way to bind the running container to a StartedTestContainer variable in tests?

[cristianrgreco]

Hi @redjolr, currently not. Could I ask what's the use case here? I'm specifically wondering why you couldn't create the container with testcontainers in the first place, that way you'd get automatic resource cleanup and other such features.

[redjolr]

Hello @cristianrgreco
The use case would be writing tests faster. When you are constantly making small changes to your tests, spinning up the containers each time is very time consuming.
I want to spin up the containers (using a testcontainers script) and after they have spinned up, I want to run my tests. Before the tests run, instead of spinning up the containers, they will check if the containers are already running. If they are not, then the tests will spin up the containers. If the containers are already running, I want to bind a running container to a StartedTestContainer.

All this will save a lot of time while developing.

EDIT: To correct myself in the question, when I say to "run some container manually", I don't necessarily mean to run the container without testcontainers. By that I mean to run the containers in a separate process from the one that my tests are running.

[cristianrgreco]

Gotcha. The tricky bit for me is instead of spinning up the containers, they will check if the containers are already running. Are you imagining this similar to docker-compose's --no-recreate option, where each container is labelled with a hash, and if run again with --no-recreate, it knows that the container is already running and won't recreate it? I guess that this could be done, something like:

const container1 = await new GenericContainer('image').withX().withY().start();
const container2 = await new GenericContainer('image').withX().withY().withNoRecreate().start();

We could use the configuration (image, X and Y in this example) to compute some hash, label the containers with it, and if the hash matches when noRecreate is set, would simply "get" the existing container.

Have I missed anything/do you have any other ideas?

[redjolr]

Or instead of the computed hash, you can use the name you pass in .withName('containername');. You wouldn't even need to have a withNoRecreate(). If there is an already running container with the name of containername, you don't try to recreate it, but you bind to it instead.

[cristianrgreco]

I'm not sure we should automatically bind to a container if one with the same name already exists, i think that behaviour would be unexpected. I think if you specify withName().withNoRecreate() then that behaviour makes sense, as you are explicitly asking for it.

The only "problem" with using the name is that to get the no-recreate functionality you now have to worry about name conflicts, and specifying withNoRecreate without a name just won't work. I think it would be nice to be able to just start a container withNoRecreate and it just works, but maybe I'm over thinking things 😄

I'd welcome a PR, if not I will look into it when I can.

[cristianrgreco]

This functionality is supported by providing withReuse() when creating a container.