Cache BuildKit state volume

[crazy-max]

follow-up https://github.com/docker/build-push-action/issues/482

Since docker/buildx#672 BuildKit state is saved in a named volume. We should be able to cache it and mount it back. This would require the possiblity to name the builder instead of a generated one.

[basicdays]

This would be insanely awesome. Would this also cover the situation of not having to set cache-from and cache-to? My understanding is that image layer caching by default is kept in buildkit?

[tmc]

This could be huge for speeding up larger or more complicated builds.

[crazy-max]

This would be insanely awesome. Would this also cover the situation of not having to set cache-from and cache-to? My understanding is that image layer caching by default is kept in buildkit?

Yes cache exporter would not be required in this case. Note that this solution would only work with GitHub Actions and a defined builder as this is a the local state.

[Richard87]

Imagine of much compute resources would be saved if everyone building docker images on github saved 30sec each time 🤯

[devminded]

@Richard87 in this article they saved way more than 30 seconds. https://evilmartians.com/chronicles/build-images-on-github-actions-with-docker-layer-caching

[Richard87]

Thanks @devminded ! I remember I already do thos tings, uts jjust when I update a node dependency or PHP dependencies that everything takes forever 🤔

[Drowze]

This is very desired feature 😄

For our ruby applications, our Dockerfile look sorta like:

FROM alpine-ruby:latest
RUN mkdir /app
COPY Gemfile Gemfile.lock .ruby-version /app
RUN bundle install

COPY . /app

...so any change to our installed dependencies (described on Gemfile and Gemfile.lock) invalidates the layer that actually install the dependencies (bundle install), meaning we fetch and install all dependencies if a single dependency is changed.

I'm sure this is a very common scenario and, if it was possible to cache the dependencies directory in a docker volume and reuse that docker volume to build new images in between triggered pipelines, I'm sure the impact would be huge!

Very much looking forward to this 👍

[crazy-max]

@Drowze

if it was possible to cache the dependencies directory

You can already cache dependencies using the RUN --mount=type=cache mount. See this example: https://github.com/portapps/portapps.github.io/blob/cde4dd6de0a2876f0311ae321f25f454cf417076/dev.Dockerfile#L7-L13

[Drowze]

@crazy-max

You can already cache dependencies using the RUN --mount=type=cache mount. See this example: https://github.com/portapps/portapps.github.io/blob/cde4dd6de0a2876f0311ae321f25f454cf417076/dev.Dockerfile#L7-L13

So using RUN --mount=type=cache will cache that mount in between builds using gha caching type? Even on GitHub managed runners (not self-hosted)? 🤔 I'll give it a try. Thanks for pointing me that @crazy-max 😄

[crazy-max]

So using RUN --mount=type=cache will cache that mount in between builds using gha caching type? Even on GitHub managed runners (not self-hosted)? 🤔

No it will not export this cache (cache-to) but it will be cached to the buildkit state (volume). You can try it locally.

[wille]

setup-buildx-action is unusable in larger builds because of the lack for buildkit state caching support

[ibalajiarun]

I have this PR out to address this: https://github.com/docker/setup-buildx-action/pull/211

[crazy-max]

I have this PR out to address this: #211

Keeping BuildKit state will not work on public runners, hence https://github.com/docker/setup-buildx-action/pull/138 to try to address this.

[ibalajiarun]

Yes, thats is true. Thanks for clarification. #211 will only work with persistent self-hosted runners.