Support container_name in docker-compose file

[krichter722]

docker-compose files which contain container_name are not supported and the creation of DockerComposeContainer fails due to IllegalStateException. This has been introduced in #1151 as a quick fix for unintuitive feedback. If I understand correctly, the option of an implementation was however not discarded, but postponed. This issue is now about the implementation.

[bsideup]

Hi @krichter722,

Would you like to work on implementing it? Also, do you see it as a blocker for you, or just a nice to have feature?

Hi @bsideup,

I would like to work on this.

[reggiemcdonald]

Has this been finished? I would be interested in working on this if it isn't.

[bsideup]

@reggiemcdonald it is still up for grabs 👍

[swanysimon]

@kiview pulling the conversation back to the original issue

#2741 (comment)

I don't really disagree with your comment on the PR, and it lines up with the general messaging from this project, but that's not necessarily why people are using this library. For a lot of us, we're transitioning manual workflows into automated tests. We just want to be able to use the same file we run docker-compose up against in automated tests. For the manual workflows, it's a huge PITA to have to go look up the generated name for each of your containers, so we attach container names to them.

It might be worth closing this issue with the same (or similar) comment you put on the PR if you believe names shouldn't be used in compose files, but otherwise I'm happy to talk through my options here.

[AlHoz]

I completely agree with @swanysimon. I need this feature only for re-using the compose file used in prod. Without it, I have to maintain two files and keep them in sync. How about the middle ground: testcontainers can parse a compose file with container names, but ignore the configuration option when run docker (names are not assigned to containers)?

[Kamveno]

I would like to contribute, can we merge?

[jlengrand]

There seems to be some pushback as to supporting the container_name feature. At the same time, I can imagine use cases where I'm not in total control of the Docker Compose file that is provided to me, say if I want to run a neighbouring microservice. Would it not be possible to at least throw a warning and ignore the parameter (at the risk of the tests failing for the users) instead throwing an exception?

I am asking because the only other option then is to either duplicate the file, or edit it temporarily. I'd even be happy if the feature was behind a flag and had to be specifically activated.

[commonquail]

Testcontainer's hard failure in preference to simply ignoring the value is difficult to justify but it is worth pointing out that in the four years that have passed since this issue was created, and five since #1151, Docker Compose has learned to generate COMPOSE_PROJECT_NAME from the containing directory's name. Therefore, in the absence of both a container_name setting and an explicitly set project name, Docker Compose will produce a container name of <containing directory>-<service name>-<n> instead of merely <service name>-<n>. Consequently, this issue has been effectively ignored into irrelevance.

[orpheusx]

@commonquail the issue was definitely ignored. A perfectly reasonable PR that simply removed the exception was opened and then closed by @kiview for, I think, specious reasons. Its not a great look for the project.

The issue itself, however, is not irrelevant. If the scope of Testcontainers is to support docker compose files then it should really not break if the file contains legit syntax.