Solves #665

I think this is the same use case as #852

Oh yeah. Look at that. You are absolutely right. I haven't seen yours.
I guess the only difference is, that mine is copying the files before the container gets started, to make files available at start time, isn't it?

still needed after #852 ?

I'll rebase and bring in the modified startup handling in order to be able to copy in files before the container is started.

Hi, just a quick checkup, is this still relevant now that we have container.copy_into_container(my_file, "/tmp/my_file.txt") ready?

@Tranquility2

At the moment, the following tests is not possible:

def test_copy_into_startup_file(transferable: Transferable):
    destination_in_container = "/tmp/my_file"

    container = DockerContainer("bash", command=f"cat {destination_in_container}")
    container.with_copy_into_container(transferable, destination_in_container)

    with container:
        exit_code = container._container.wait()
        stdout, _ = container.get_logs()
        assert exit_code["StatusCode"] == 0
        assert stdout.decode() == "hello world"

This is what I ment with

I guess the only difference is, that mine is copying the files before the container gets started, to make files available at start time, isn't it?

Who it works now: when the container is started, the file is copied into the started container.
How is should be: the container should be created, then the file is copied into and then the container gets started having all the files available at start time.

This is often crucial like when you want to copy in a config file which is used by the entrypoint script or even more: if you copy in the actual entrypoint script the container should start with.

@rhoban13 I've updated this PR based on your changes. Maybe you can have a quick glimpse if it seems ok for you.

Ah - I see the use case, I suspect this will be a much larger piece of work.

You're introducing here the notion of createing a container prior to starting it, which I think is a good idea, but feels like a different piece or work. I believe @alexanderankin has talked about the need do this, but quick glance I'm not seeing any issues tracking that work.

2 immediate workarounds I can think of would be:

1. Copy the files into an image and pass that image into the Container
2. Mount instead of copying

imo its ok if we start implementing create before start here (this is not a soc2 workplace where each PR needs an approved ticket), but the wait method idk if we want that at all, and image pulling would probably need a follow up to account for things like private mirrors, image pull policy (never, ifabsent, always), etc. other than that it looks ok, right?

ok so lets centralize the discussion about creating before starting #997 because maybe there are some nuances to discuss although im not sure what they are, my approach was going to be to release some release candidates before the next minor version to test this stuff out

Codecov Report

❌ Patch coverage is 83.33333% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 82.97%. Comparing base (23aca0b) to head (6659ff5).
⚠️ Report is 1 commits behind head on main.

@@            Coverage Diff             @@
##             main     #976      +/-   ##
==========================================
- Coverage   83.05%   82.97%   -0.09%     
==========================================
  Files          16       16              
  Lines        1700     1721      +21     
  Branches      186      189       +3     
==========================================
+ Hits         1412     1428      +16     
- Misses        234      236       +2     
- Partials       54       57       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.