testcontainers-java icon indicating copy to clipboard operation
testcontainers-java copied to clipboard

Support container_name in docker-compose file

Open krichter722 opened this issue 5 years ago • 9 comments

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.

krichter722 avatar Mar 24 '20 10:03 krichter722

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?

bsideup avatar Mar 24 '20 10:03 bsideup

Hi @bsideup,

I would like to work on this.

ghost avatar Mar 26 '20 07:03 ghost

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

reggiemcdonald avatar May 13 '20 03:05 reggiemcdonald

@reggiemcdonald it is still up for grabs 👍

bsideup avatar May 13 '20 08:05 bsideup

@kiview pulling the conversation back to the original issue

https://github.com/testcontainers/testcontainers-java/pull/2741#issuecomment-1225513472

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.

swanysimon avatar Aug 29 '22 17:08 swanysimon

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)?

AlHoz avatar Sep 13 '22 13:09 AlHoz

I would like to contribute, can we merge?

Kamveno avatar Sep 26 '23 19:09 Kamveno

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.

jlengrand avatar Oct 20 '23 21:10 jlengrand

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.

commonquail avatar Mar 29 '24 16:03 commonquail