As a follow-up, would you see it doable to contribute an implementation to the compose provider? 🤔

Codecov Report

Merging #347 (28d20ca) into master (6185475) will increase coverage by 0.58%.
The diff coverage is 61.53%.

@@            Coverage Diff             @@
##           master     #347      +/-   ##
==========================================
+ Coverage   61.53%   62.11%   +0.58%     
==========================================
  Files          15       15              
  Lines         993     1011      +18     
==========================================
+ Hits          611      628      +17     
+ Misses        290      286       -4     
- Partials       92       97       +5     

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6185475...28d20ca. Read the comment docs.

I will checxk to add it to the ComposeProvider

About the Compose Part: There are no containers exposed.
The compose implementation as it is really just runs docker compose and can check for availability of a container.
It doesn't even allow copying files into a running container.
from what I see this qould take quite a big effort to achieve.

About the Compose Part: There are no containers exposed.
The compose implementation as it is really just runs docker compose and can check for availability of a container.
It doesn't even allow copying files into a running container.
from what I see this qould take quite a big effort to achieve.

Sure thing. I can create an issue to add the support to the compose provider. Meanwhile, this LGTM

Hello! Thank you for your contribution! I had a chat with @mdelapenya via Slack and I would like to know what you think about this:

	CopyFileToContainer(ctx context.Context, hostFilePath string, containerFilePath string, fileMode int64) error
	CopyFileFromContainer(ctx context.Context, filePath string) ([]byte, error)

I see how your function will may come from what we have done with CopyFileToContainer but now that I see it if I think we made a mistake there (I think we should deprecate that in favor of something else).

I think the right signature should be:

	CopyFileFromContainer(ctx context.Context, filePath string) (io.ReadCloser, error)

This works a bit better over the network and it give more control to the end user who can decide what to do with an io.Reader.

I understand the extra code you wrote sounds like a useful utility function but at the end it can be replaced with a few line as explained here https://pkg.go.dev/io/ioutil#ReadAll and I don't think it should be something to include as part of the testcontainer library.

What do you think?

Hey @gianarb,
thanks for your feedback :)
I have updated my Pr to use the signature you suggested.
With your suggestions in mind I also thought it would be better to eliminate all eager reading.
I wrapped the whole tar reader to enable closing of the underlying ReaderCloser and to return a valid object.
You think this would work better?

Cheers,
Jochen

Hey @mdelapenya or @gianarb ,
are you interested in this? Anything else you would like to see changed/added in here?
Cheers,
Jochen

BTW, the GH action complains about source formatting in the docker.go file: https://github.com/testcontainers/testcontainers-go/pull/347/checks?check_run_id=3516875570

Could you run ./scripts/checks.sh and verify the issue? 🙏

@mdelapenya fixed it, forgot to run "go fmt" ...

And just so you know what this is for:
Thanks to a few hints from @bsideup I was able to implement k3s-based integrationtests for k8s.
The only missing piece was this function.

Here is the example of what I am using it for:
https://github.com/codepitbull/k8sit/blob/main/gok3s/k8sit/testcontainer_test.go

@codepitbull omg this is great! 💯 FYI the original k3s minimal container was created by @rnorth, I am just a messenger here :D

Thank you for this!!

Thanks to you and the other maintainers!
We are really happy with it for our integration tests :)