feat: adding the ability to get container for any service via docker-compose

[marcpfuller]

What does this PR do?

This adds GetServiceContainer method to LocalDockerCompose

Why is it important?

My team and I are working to build a automated integration testing using testcontainers-go for our project. All of our services were written up to use docker-compose, and we would have needed to write code to create containers for each service we had to interact with containers. This PR is important, because it saves developers time to write individual container code if they have many services to test.

Examples

See GetServiceContainer test understand how to use it

Signed-off-by: Marc-Philippe Fuller [email protected]

[mdelapenya]

Hi @marcpfuller thanks for this contribution! At first sight it's clear so LGTM.

I'd like to tell you that we are releasing 0.14.0 very soon, and would like you to take a look at #476, which refactors all docker compose APIs to use the native Go SDK for compose, instead of the local shell. My comment on https://github.com/testcontainers/testcontainers-go/pull/476#issuecomment-1238399054 explains the need to postpone anything compose to a future 0.15.0, which will eventually contain all the DC refactor, and this PR could be part of it.

Does it make sense to you?

[marcpfuller]

@mdelapenya Makes sense to me.

I looked through the PR #476 and it looks like it does add in the feature get the service container already in compose_api.go, which is awesome. The PR looks to have rename the original compose.go to compose_local.go, which does not have my PR. will you be keeping the new compose_local.go?

[mdelapenya]

Hi @marcpfuller we have merged #476, which adds native support for docker compose. Would you mind revisiting this PR and update to that code? I can assist if needed, or we can even ping @baez90 for that.

The PR looks to have rename the original compose.go to compose_local.go, which does not have my PR. will you be keeping the new compose_local.go?

Yes, the local docker compose has been kept, although deprecated in favor of the native libraries, which are more consistent that shelling out the local binary for compose.

Thanks in advance

[marcpfuller]

yes I will rebase my fork then make the necessary changes

[mdelapenya]

yes I will rebase my fork then make the necessary changes

Is using the native Compose support in your plans? I ask because I'm not sure if we should add more features to a deprecated struct like LocalDockerCompose