-
-
Notifications
You must be signed in to change notification settings - Fork 266
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
chore: speedup docker build time #6787
base: unstable
Are you sure you want to change the base?
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## unstable #6787 +/- ##
============================================
- Coverage 61.88% 61.88% -0.01%
============================================
Files 562 562
Lines 59309 59331 +22
Branches 1916 1916
============================================
+ Hits 36703 36715 +12
- Misses 22563 22573 +10
Partials 43 43 |
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.
need to confirm this does not increase the image size
I added some experiment using a lodestar base builder image. This reduce the need to either use a big image or update via |
@@ -0,0 +1,2 @@ | |||
FROM node:20-alpine | |||
RUN apk update && apk add --no-cache g++ make python3 && rm -rf /var/cache/apk/* |
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.
What was the argument against using the node:20
as builder image?
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.
For some unclear reason it fails to build native libs in the second stage. Might be the original reason for using alpine
.
Also this one would be smaller and offers more opportunity for further tweaks down the road.
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.
I am really not sure it's worth to have a separate builder image just for these dependencies as the layer will always be retrieved from local cache after the first local build, and even if it is executed it just took 11 seconds on my machine.
The issues I see with using a separate builder image is that right now we automatically use the latest 20.x version which is good to get security updates in. There is also extra maintenance to keep this up-to-date if it's not part of the CI. Although we could build this image before running the main docker build.
|
||
```bash | ||
yarn config set yarn-offline-mirror .yarn/yarn-offline-mirror | ||
mv ~/.yarnrc ./ # `yarn config` commands are always global, make `.yarnrc` specific to this project |
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.
What if someone has settings in their global yarn config? can't we just commit a .yarnrc
to the project with this setting in it?
Motivation
Speedup docker builds
Description
Tweak current Docker build process to improve build speeds.
This is achieved by:
apk
every runUsing regular node images comes at a higher download cost (image is bigger) but is cached.
slim
images do not ship with the necessary tooling.Note that the current Docker build creates a multi-platform Docker image (
arm64
andamd64
). We can probably improve things further by having a dedicated Dockerfile for dev usage.Results
Before
1st run: 5m 22s
Subsequent runs, after code change: 4m 52s
After
1st run: 3m 16s
Subsequent runs, after code change: 2m 32s