2472: Add support for container_name in docker-compose file

[reggiemcdonald]

Closes: #2472

This PR adds support for container_name in the docker-compose file by pulling the container names out in ParsedDockerComposeFile and adding some additional logic in DockerComposeContainer

This is my first time contributing to the repo, so any feedback is welcomed.

[reggiemcdonald]

I'm not really sure about this failing CI. Any suggestions? I just rebased with master, and it wasnt failing before the rebase

[bsideup]

@reggiemcdonald I just triggered a re-run, there was some issue with downloading Gradle stuff

[reggiemcdonald]

@bsideup thanks!

[wnyffenegger]

@rnorth @bsideup @kiview having this feature is a blocking issue for me is there a plan to merge this change in?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this is a mistake, please reply to this comment to keep it open. If there isn't one already, a PR to fix or at least reproduce the problem in a test case will always help us get back on track to tackle this.

[d3vAdv3ntur3s]

Thanks @reggiemcdonald great work

Is this still looking to be merged in? Currently the latest version (as of writing this) is 1.15.2 and this issue is still casuing problems.

[james-toussaint]

Hi @reggiemcdonald, thank you! Do you have any plan on merging it @rnorth?

[kadaan]

@reggiemcdonald Can this get merged?

[eitzenbe]

Any update on landing this?

[matthieusb]

Hello. I had the same issue recently, I would be grateful if this PR could be merged. Thanks for the hard work !

[cunhap]

@rnorth @bsideup @kiview Can this PR be merged, please?

[svalexxx]

Is there any news about this PR?

[swanysimon]

@bsideup or @reggiemcdonald , what's the status here? If you don't have time or energy here, I'm happy to take over the PR

[jghoman]

Would also love to see this merged, and can take it over if someone needs to. Status?

[kiview]

Thanks for the PR @reggiemcdonald, but unfortunately we have to close it. Mainly, there are 2 reasons why we don't want to add support for container_name to DockerComposeContainer:

1. It requires us to further parse the Docker Compose file and its format has been slightly volatile in the past. So we generally want to avoid further semantically parsing the Docker Compose file, independent from the actual container_name key.
2. Using container_name would break existing DockerComposeContainer features, like scaling.
3. As the Testcontainers library, we want to avoid the usage of fixed things, such as ports, names, etc., since those introduce the anti-pattern of integrated tests that can fail depending on the state of the environment in which they are running.

[orpheusx]

@kiview The reasons for closing this seem fairly arbitrary from my point of view. Responding to your numbered reasons in order:

1. Format volatility ebbs and flows over time but if the project wants to support compose files at all it seems better to at least not actively get in the way (by throwing exception over valid syntax.) My sense is that V2 has been more stable. (Note: the issue with container_name applies to the newer ComposeContainer as well as the now deprecated DockerComposeContainer.)
2. Not sure how this would break scaling. An issue with Testcontainers Cloud?
3. I agree that users should avoid environment state dependencies but providing supporting docker-compose files at all seems to be a pragmatic choice that recognizes the need that have been expressed above and in the original ticket, Support container_name in docker-compose file #2472.

For what it's worth, I just ran into this issue and would really like to see a solution because, in most other ways, Testcontainers is awesome.