-
Notifications
You must be signed in to change notification settings - Fork 537
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
Efficiently cache docker build #21914
Conversation
32c6ddb
to
a40b50f
Compare
9dcd191
to
89b4e82
Compare
e162495
to
ad43992
Compare
ad43992
to
bc57245
Compare
Comparison of master to this branch with different scenarios, changing different types of files that would invalidate different stages of the build. Running
|
So trying to use this... After running
What am I supposed to run ? I tried
And it looks like it's rebuilding from the beginning - with layers caching, but it's not as fast as I'd expect given there are no changes (it's rebuilding dependencies, re-running locale compilation, redoing the copy and assets, taking 60 sec total) |
You can ignore the warning as the make command is using the cache type=locale and saving to your local file system instead of pushing to a registry. You can look at what the make command executes to see how you'd repeat with raw docker commands. TLDR; you have to make sure to use buildkit and you have to make sure to use the docker-container driver to enable the full scope of caching. docker build as you have it will likely miss out on several opportunities because of one or the other or both things. part of the reason why I added the make command is to normalize that flow. I don't want to have to remember what exact magic to pass, just make it work. Though it is probably a good thing to add --load so that the built image is added to the docker daemon, since we are using a custom builder I'm not 100% sure if it is automatically available or we have to pass load. I can check that and update if it doesn't pass it up the chain. |
Also, to clarify the error you got, when you run |
Cool, adding
Ah right, I figured I needed to point it to the right place but forgot the directory was entirely custom, that makes sense now, thanks. |
There needs to be some docks written and mostly pointing to other places for this I think :) |
78e9d8e
to
7200896
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please update the PR title to something more descriptive before merging.
I'd like to merge this first #21930 The actions will be super useful in testing this. I would like to do a bit more testing before merging. |
- cache npm/pip dependencies across builds - add clear logging to npm install for cache hit/miss - move copy npm files to update_assets
- splitting to stages offers better caching of layers and more efficient use of disk/time - The initial gains will be with better caching of locale compilation, but will expand as we can move more logic from the final stage TODO: split up apt depedencies to specific stages, move update_assets to pre-final stage to prevent re-running on every build with a * file change.
780197d
to
b5e7153
Compare
relates to : mozilla/addons#1992
Description
Using more efficient caching within our docker build to speed up successive builds.
Context
This opens up faster build times both locally and in CI and makes the idea of building images more frequently a lot more palletable.
Testing
This PR adds a make command to build a local docker image
This will build an image. If you want to really see the cache benefit, then first prune your local layer cache
If you have already run
make build_docker_image
you should prune the builder cache as wellThis is like runnig for the first time. It will take a while.
Then modify the package.json or one of the requirements files.
Run the build again.
You will see that pip is using "cached" versions of dependencies which have already been installed. That is the more aggressive layer caching kicking in.
You'll also see that if you change other files in the code base, it won't necessarily reinstall dependencies. You can compare that behavior to running the same commands on master.