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

[Enhancement]: Get FilePaths for DockerCompose

Open mhogara opened this issue 1 year ago • 5 comments

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. 🙂

mhogara avatar Apr 25 '24 18:04 mhogara

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!

mdelapenya avatar Apr 30 '24 15:04 mdelapenya

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.

mhogara avatar May 01 '24 20:05 mhogara

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

mdelapenya avatar May 02 '24 07:05 mdelapenya

@mhogara the readers feature was released in v0.31.0, and latest is `v0.33.0. Do you think we can close this as resolved?

Thanks!

mdelapenya avatar Aug 22 '24 12:08 mdelapenya

@mdelapenya I unfortunately don't have the time to test it out. I'll leave it up to your discretion; if I do have other comments/time to test it out, I can come back to this.

mhogara avatar Aug 22 '24 13:08 mhogara