plan/run_sh/store: providing a directory path doesn't copy the content of it

[Bidon15]

What's your CLI version?

0.86.12

Description & steps to reproduce

1. Try to run an bash plan command
2. Provide a store path, so the content can be mounted for the plan.add_service part later

results = plan.run_sh(
        # image and others 
        store=[
            "/foo/bar/",
        ],
    )
 plan.print(results.files_artifacts)

Desired behavior

Content under bar is stored in the context for mounting in later stages like plan.add_service()

Note: adding an asterisk to /foo/bar/* fixes this behaviour for now

What is the severity of this bug?

Papercut; this bug is frustrating, but I have a workaround.

What area of the product does this pertain to?

SDK: the Software Development Kit libraries - Typescript, Go, etc.

[mieubrisse]

Extra context: @Dartoxian and myself have both hit this exact same issue. It's pretty overwhelming that folks expect a store'd directory to copy the contents, not the directory itself.

IMPLEMENTATION IDEA: we could make the default behaviour "if it's a directory, copy the contents. only if the user adds an explicit / at the end, e.g. /path/to/my/dir/, will we copy the directory itself"

[Bidon15]

IMPLEMENTATION IDEA: we could make the default behaviour "if it's a directory, copy the contents. only if the user adds an explicit / at the end, e.g. /path/to/my/dir/, will we copy the directory itself"

ngl, pretty much 🅱️ased idea

[leovct]

Extra context: @Dartoxian and myself have both hit this exact same issue. It's pretty overwhelming that folks expect a store'd directory to copy the contents, not the directory itself.

IMPLEMENTATION IDEA: we could make the default behaviour "if it's a directory, copy the contents. only if the user adds an explicit / at the end, e.g. /path/to/my/dir/, will we copy the directory itself"

+1 I also ran into this problem when prototyping with kurtosis :)

[h4ck3rk3y]

This is interesting as upload_files has this behavior but run_sh
doesn't so there is inconsistency; store_service_files has this behavior as they use the same backend

note that the "fix" would be a breaking change will affect ethereum-pacakge at least