Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Enhancement]: Get FilePaths for DockerCompose #2516

Open
mhogara opened this issue Apr 25, 2024 · 3 comments
Open

[Enhancement]: Get FilePaths for DockerCompose #2516

mhogara opened this issue Apr 25, 2024 · 3 comments
Labels
enhancement New feature or request

Comments

@mhogara
Copy link

mhogara commented Apr 25, 2024

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:

ComposeFilePaths []string

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 mhogara added the enhancement New feature or request label Apr 25, 2024
@mdelapenya
Copy link
Collaborator

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
Copy link
Author

mhogara commented May 1, 2024

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 #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
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants