Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cache BuildKit state volume #122

Open
crazy-max opened this issue Jan 17, 2022 · 14 comments · May be fixed by #138
Open

Cache BuildKit state volume #122

crazy-max opened this issue Jan 17, 2022 · 14 comments · May be fixed by #138

Comments

@crazy-max
Copy link
Member

follow-up docker/build-push-action#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
Copy link

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
Copy link

tmc commented Jan 19, 2022

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

@crazy-max
Copy link
Member Author

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
Copy link

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

@devminded
Copy link

@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
Copy link

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
Copy link

Drowze commented Feb 17, 2022

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
Copy link
Member Author

@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
Copy link

Drowze commented Feb 17, 2022

@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
Copy link
Member Author

crazy-max commented Feb 17, 2022

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
Copy link

wille commented Dec 12, 2022

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

@ibalajiarun
Copy link

I have this PR out to address this: #211

@crazy-max
Copy link
Member Author

I have this PR out to address this: #211

Keeping BuildKit state will not work on public runners, hence #138 to try to address this.

@ibalajiarun
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants