Allow exporting cache mounts for use in CI systems.

[bendavies]

Hi,

Various CI systems are the ability to cache and restore files/directories between builds.
It would be very to be able to export type=cache mounts, which could then be saved and restored between CI runs, allowing for faster builds.

Thanks!

[tonistiigi]

You can use a separate stage to export/import data into cache mounts. Not sure if this will improve the performance of the builds as regenerating cache mounts is usually faster than import/export.

Eg.

from alpine as cache-import
run --mount=type=cache,target=/cache tar xvf https://mycache.tar -C /cache

from alpine cache-export
run --mount=type=cache,target=/cache tar cvf /cache.tar /cache

edit: also, https://dockercommunity.slack.com/archives/C7S7A40MP/p1584648659208500?thread_ts=1584642414.203700&cid=C7S7A40MP

[bendavies]

@tonistiigi thanks for the reply, but I can't see from your example how i would:

1. get cache.tar out of the resulting image onto the local filesytem so CI can save it. maybe docker create then docker cp ?
2. Get a CI restored cache.tar on the local filesytem into the docker build context for use in --mount=type=cache

Am i misunderstanding you?

[tonistiigi]

You can use -o to get local files out of build and build context to get files into build. But this all has overhead that will make your cache useless in practical cases. In my example, I just showed using an external server for storage that might be a bit more performant for this.

[bendavies]

thanks @tonistiigi i'll give this a go.
I guess what i'm asking for here is build time volumes supporting both read and write.

Cheers!

[jameshowison]

Could someone expand on using -o here to get a local copy? I'm not sure where to put that flag :) I checked the documentation for buildx, tar, and I searched copying files from containers. That last link assumes the source is a "regular" container. I'm not sure how to address the buildx builder as a docker container? Which is sort of a variant of #255?

[tonistiigi]

@jameshowison https://github.com/docker/buildx#-o---outputpath-typetypekeyvalue

[Fuco1]

But this all has overhead that will make your cache useless in practical cases.

I don't understand this statement. A big apt install or compiling a lot of packages from source can take anywhere from minutes to hours. Having a cache in such a case is extremely practical.

[hansbogert]

I don't understand this statement. A big apt install or compiling a lot of packages from source can take anywhere from minutes to hours. Having a cache in such a case is extremely practical.

True, but why not rely on 'normal' docker layer caching in combination with cache-from ? Also, what will you cache with a compilation? intermediate library files?

[jameshowison]

It's the situation where you add a single python/r package and the entire docker layer needs to be rebuilt. And one layer per package isn't feasible (too many separate install statements in the dockerfile).

…

On Tue, May 25, 2021 at 9:35 AM Hans van den Bogert < ***@***.***> wrote: I don't understand this statement. A big apt install or compiling a lot of packages from source can take anywhere from minutes to hours. Having a cache in such a case is extremely practical. True, but why not rely on 'normal' docker layer caching in combination with cache-from ? Also, what will you cache with a compilation? intermediate library files? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#244 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAWOUQEYU5FQCMONRLRRZTTPOYRZANCNFSM4LSAUOWQ> .

[philomory]

It's the situation where you add a single python/r package and the entire docker layer needs to be rebuilt. And one layer per package isn't feasible (too many separate install statements in the dockerfile).

It's even worse than that, actually: even if you want to break every single pacakge into its own layer with its own install statement in the Dockerfile, that doesn't actually solve the problem because layers are ordered, so if the first package you listed gets updated, it still invalidates the cache for all subsequent packages.