search

testcontainers / testcontainers-go

Testcontainers for Go is a Go package that makes it simple to create and clean up container-based dependencies for automated integration/smoke tests. The clean, easy-to-use API enables developers to programmatically define containers that should be run as part of a test and clean up those resources when the test is done.
https://golang.testcontainers.org
MIT License
3.36k stars 460 forks source link

[Enhancement]: Get FilePaths for DockerCompose #2516

Open mhogara opened 3 months ago

mhogara commented 3 months ago

Proposal

After calling NewDockerCompose, I would like there to be a way to get the filepaths associated with that compose stack. i.e. something like this: compose, err := tc.NewDockerCompose(filename) // Print filepaths equivalent to "filename" fmt.Println(compose.FilePaths) There is a way to do that in a LocalDockerCompose, see below: https://github.com/testcontainers/testcontainers-go/blob/fa5f304ac88038258b2a9777b928a9bdb4c3aaa7/modules/compose/compose_local.go#L52 However, since that is being deprecated, I would like to also have a way to do that from calling NewDockerCompose. I've searched the compose/compose.go and compose/compose_api.test.go files and haven't found anything that looks like an exposed file path, so I'm assuming it doesn't exist. I haven't been able to find anything on it in the documentation either, but in the case some function exists to retrieve the existing filepaths, then this is really an enhancement for the doc. 🙂

mdelapenya commented 2 months ago

Hi @mhogara could you share the use case for that? The dockerCompose struct has a reference to all the configs, but it's private. On the other hand, since #2509 it's possible to pass a reader for the compose files so you can build them on the fly, or download them from the internet. What paths would you expect from them in those cases?

In any case, having more context about your use case would be of interest to understand better what to do here.

Thanks!

mhogara commented 2 months ago

My use case is actually not too far off from what #2509 achieved. I was working on a helper function that generated a Docker Compose file on the fly and then brings up the container. That same helper package then has a wrapper function on composeDown (or more accurately, originally the old Local Docker compose equivalent) which also removes the file.

But in my case, there was no struct involved and I had just passed around the compose variable itself since it also contained a reference to the filenames. And I could use that public reference to remove the files(very similarly to as testcontainer-go does here: https://github.com/mdelapenya/testcontainers-go/blob/1add9d3a4ddef1130ee5f38d54975c0211667b84/modules/compose/compose_api.go#L259).

The work with readers at https://github.com/testcontainers/testcontainers-go/pull/2509 might be enough to get me by. The only possible problem I can think of is that I had created a flag to the compose.Down wrapper that allowed the files to remain/not be removed. And that doesn't seem possible with the current reader feature. I'd have to wait until this work is released to truly test it out and get back to you.

We can come back to this after the next release is out, but other than that thanks for your help and let me know if there is anything I can clarify.

mdelapenya commented 2 months ago

I'd have to wait until this work is released to truly test it out and get back to you.

In order to test it, you can always consume the main branch in your project:

go get github.com/testcontainers/testcontainers-go@main