The `DockerBuild cacheFrom` docs say this ``` An optional Ca

Question

The `DockerBuild cacheFrom` docs say this ``` An optional CacheFrom object with information about the build stages to use for the Docker build cache This parameter maps to the cache from argument to the Docker CLI If this parameter is `true` only the final image will be pulled and passed to cache from if it is a CacheFrom object the stages named therein will also be pulled and passed to cache from ``` What does this mean If this parameter is `true` only the final image will be pulled and passed to cache from

white-balloon-205 · Answer

The default behavior of ` cache from` in docker is to only cache the final stage if you are using multi stage builds So if you pass `true` here you get that behavior But if you also want to cache other stages which in general you do if you are sensitive to build caching performance then you can specify stage names to cache in the CacheFrom object

full-dress-10026 · Answer

Hmm I was hoping that would help work around this <https github com pulumi pulumi docker issues 23> Have you guys discovered any workarounds for the time being

lemon-spoon-91807 · Answer

Unfortunately This appears to be an intrinsic way about how docker works with pulumi not being in the mix One option is to take control of docker externally to pulumi however you want You then push pull etc whenever you think it is right to do so You then just use that image id you ve produced and provide that to pulumi

lemon-spoon-91807 · Answer

We have a work item to sort of improve things here in the future specifically by potentially having a mode where we use the file system as the source of truth so if the FS doesn t change we don t rebuild docker stuff

lemon-spoon-91807 · Answer

note this is not proper docker semantics because a docker build can and will produce new builds even if the FS stays the same

lemon-spoon-91807 · Answer

so we d need to make this something you could opt in out of

full-dress-10026 · Answer

gt the FS stays the same Does this take into account the last modified timestamps of files Or simply the contents of the files

lemon-spoon-91807 · Answer

Haven t fully designed it out in general we use contents for hashing but we could ahve a contents+timestamps approach if you wanted that

lemon-spoon-91807 · Answer

but then you might have different timestamps on different machines thus defeating the purpose

full-dress-10026 · Answer

I d prefer contents

lemon-spoon-91807 · Answer

oh good then slightly smiling face

lemon-spoon-91807 · Answer

that s waht we already do for things lke Lambdas

lemon-spoon-91807 · Answer

to know that we don t have to reupload your node modules dir every time

full-dress-10026 · Answer

FWIW skipping Docker builds when the FS hasn t changed will be a nice perf improvement Right now running `pulumi up` with no changes takes 35s mostly due to the Docker builds If you could detect no FS changes and skip the Docker build I bet that number would be closer to 10s