-
Notifications
You must be signed in to change notification settings - Fork 78
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
Find a way to cache the npm install
step during nox -s dev
#887
Comments
@allisonking @ssangervasi do either of you have any thoughts/experience here? I was thinking we could load local node modules to speed this process up...some kind of check to see if local modules exist than use those, otherwise run an This might get messy though because we need to guarantee that the versions are the same and such? Maybe npm has some features here I just don't know about that could help solve this problem |
It looks like right now any time any file in So # install node modules
COPY clients/admin-ui/ .
RUN npm install Changes to COPY clients/admin-ui/package.json .
RUN npm install Then later do the |
Hmm yeah I tried to multi-stage it to make the frontend get out of the backend's way, and only build itself on prod, but I guess now that we have Also, for what it's worth, here are the times it took for my last
So the slowest parts for me are:
In fact, |
@allisonking out of curiosity did |
@allisonking good catch there! definitely would be low-hanging fruit to move I'm also a big curious why the my run times:
curious to see that we got some drastically different times for some steps, our caches must've been different |
How do I tell? And yeah that's strange we got such different results @ThomasLaPiana 🤔 presumably I work more on the frontend files and you on the backend, but then I'd expect the reverse since we're modifying those files more 😵 |
some of it might be down to platform differences (i believe mac's run on a VM of some sort, I'm on windows so its running directly on linux subsystem) but I'm not sure what impact that would have functionally on different steps. It is curious though |
I don't know of a way to know for sure other than to delete the container all together. I'd be curious to know what results you both get with no cache at all, then with a rebuild right after when there is cache. You would be sure to be in the same states of cache that way so in theory you would see close to the same times. That would at least tell if the initial difference you saw was related to cache. |
|
My results on Mac with the same commands. Interesting yours still mentions cache. nox > Running session build(test)
nox > Creating virtual environment (virtualenv) using python in .nox/build-test
nox > docker build --target=prod --tag ethyca/fidesctl:local .
[+] Building 593.9s (30/30) FINISHED
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 2.74kB 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 423B 0.0s
=> [internal] load metadata for docker.io/library/node:16 1.0s
=> [internal] load metadata for docker.io/library/python:3.8-slim-buster 1.0s
=> [internal] load build context 23.0s
=> => transferring context: 494.75MB 22.9s
=> [base 1/2] FROM docker.io/library/python:3.8-slim-buster@sha256:65db770a0126c5f032de60 7.0s
=> => resolve docker.io/library/python:3.8-slim-buster@sha256:65db770a0126c5f032de607b8b8 0.0s
=> => sha256:6258dcdb5fea7b710bfcfc3c889e022e4c6e9dd0ea962cfa73fbc130eff2 1.37kB / 1.37kB 0.0s
=> => sha256:8efad32061c2124947b46db2be6969b6698a00f374fbd57048fc2f701ac6 7.53kB / 7.53kB 0.0s
=> => sha256:65db770a0126c5f032de607b8b8ae7207ec2adc17420e54af4d129b1d3b0 1.86kB / 1.86kB 0.0s
=> => sha256:d59e69a18eecf7f63d9379a602a0f904b298202d4fb9afdd34270c2f47 11.29MB / 11.29MB 4.8s
=> => sha256:1525f74216cf07879be0c575e5ed58c1ae4058f4c5d7ab3cdca10d657f49ab08 233B / 233B 4.9s
=> => extracting sha256:d59e69a18eecf7f63d9379a602a0f904b298202d4fb9afdd34270c2f4797e53d 0.8s
=> => sha256:301f2616d6071fe9be7e9dbe77c4829ece48519e10b8d27de853160bc18d 3.17MB / 3.17MB 5.3s
=> => extracting sha256:1525f74216cf07879be0c575e5ed58c1ae4058f4c5d7ab3cdca10d657f49ab08 0.0s
=> => extracting sha256:301f2616d6071fe9be7e9dbe77c4829ece48519e10b8d27de853160bc18d467e 0.9s
=> [frontend 1/5] FROM docker.io/library/node:16@sha256:8951351b7c6a2f8ff9ec25eccc087d37 25.6s
=> => resolve docker.io/library/node:16@sha256:8951351b7c6a2f8ff9ec25eccc087d37a8aeccf9bf 0.0s
=> => sha256:8d6f1451981514e25c21542f5c7ee9bb90052b8856b484ce47294cbf1f 49.23MB / 49.23MB 2.7s
=> => sha256:8ccc9fb4baf6e7f2e6ee18ed689c8ee1171c6751c8bbd317d580a193da27 7.72MB / 7.72MB 1.1s
=> => sha256:8951351b7c6a2f8ff9ec25eccc087d37a8aeccf9bf911888ff13c7622346 1.21kB / 1.21kB 0.0s
=> => sha256:407013b47e765f5e900729141d6668a3588b484af4082b232e586041e5bb 2.21kB / 2.21kB 0.0s
=> => sha256:90930c7a6dd7f8531d230a2206f35582a1ac1bfb480063ca55dc4e4899dc 7.75kB / 7.75kB 0.0s
=> => sha256:620d55693ed5943ab298346d9ccafefdd6d6f33994e6820a857737df89b6 9.77MB / 9.77MB 0.7s
=> => sha256:82dcb0fa2b6020cd95c3972ec0fe03da38862f57574fe03a49360713d6 52.17MB / 52.17MB 3.5s
=> => sha256:d75d85ab89337b32fb8b4e0454a157fa71a765a1daf512255323edd5 184.07MB / 184.07MB 8.8s
=> => extracting sha256:8d6f1451981514e25c21542f5c7ee9bb90052b8856b484ce47294cbf1fd5a234 3.7s
=> => sha256:58af0698dc7f636576a444c050fdf327087c17ca5f52bf8691359e902a42 4.09kB / 4.09kB 2.8s
=> => sha256:915a9c8840243d713b6c11835a772389bb3277c64fba1bd36cb619b05b 34.22MB / 34.22MB 5.2s
=> => sha256:798bae4139c68cdd5e53b6ff9c601d8cbd88c94cfe9df501df3e7beadd80 2.29MB / 2.29MB 3.7s
=> => sha256:c76fba79a64114d60394b5c76efbb7460b3fad11363da2089081a49ba6ec1482 451B / 451B 3.8s
=> => extracting sha256:8ccc9fb4baf6e7f2e6ee18ed689c8ee1171c6751c8bbd317d580a193da27a5f1 0.5s
=> => extracting sha256:620d55693ed5943ab298346d9ccafefdd6d6f33994e6820a857737df89b65f3a 0.6s
=> => extracting sha256:82dcb0fa2b6020cd95c3972ec0fe03da38862f57574fe03a49360713d6f415d6 4.7s
=> => extracting sha256:d75d85ab89337b32fb8b4e0454a157fa71a765a1daf512255323edd5f3f0afe7 11.2s
=> => extracting sha256:58af0698dc7f636576a444c050fdf327087c17ca5f52bf8691359e902a42a86e 0.0s
=> => extracting sha256:915a9c8840243d713b6c11835a772389bb3277c64fba1bd36cb619b05ba8417a 0.9s
=> => extracting sha256:798bae4139c68cdd5e53b6ff9c601d8cbd88c94cfe9df501df3e7beadd80185b 0.1s
=> => extracting sha256:c76fba79a64114d60394b5c76efbb7460b3fad11363da2089081a49ba6ec1482 0.0s
=> [base 2/2] RUN pip install -U pip 26.8s
=> [frontend 2/5] WORKDIR /fides/clients/admin-ui 0.6s
=> [frontend 3/5] COPY clients/admin-ui/ . 3.6s
=> [frontend 4/5] RUN npm install 22.8s
=> [builder 1/14] RUN : && apt-get update && apt-get install -y --no-instal 89.8s
=> [frontend 5/5] RUN npm run export 49.2s
=> [builder 2/14] RUN : && apt-get update && apt-get install -y --no-instal 16.5s
=> [builder 3/14] RUN curl https://packages.microsoft.com/keys/microsoft.asc | apt-key a 6.4s
=> [builder 4/14] RUN curl https://packages.microsoft.com/config/debian/10/prod.list | t 0.6s
=> [builder 5/14] RUN : && apt-get update && apt-get install -y --no-instal 20.8s
=> [builder 6/14] COPY dev-requirements.txt dev-requirements.txt 0.0s
=> [builder 7/14] RUN pip install -r dev-requirements.txt 76.3s
=> [builder 8/14] COPY requirements.txt requirements.txt 0.0s
=> [builder 9/14] RUN pip install -r requirements.txt 212.7s
=> [builder 10/14] COPY optional-requirements.txt optional-requirements.txt 0.0s
=> [builder 11/14] RUN pip install -r optional-requirements.txt 81.6s
=> [builder 12/14] COPY . /fides 5.5s
=> [builder 13/14] WORKDIR /fides 0.0s
=> [builder 14/14] RUN mkdir -p src/fidesapi/build/static 0.3s
=> [prod 1/3] RUN python setup.py sdist 3.1s
=> [prod 2/3] RUN pip install dist/fidesctl-*.tar.gz 37.9s
=> [prod 3/3] COPY --from=frontend /fides/clients/admin-ui/out/ /fides/src/fidesapi/build 0.1s
=> exporting to image 7.2s
=> => exporting layers 7.2s
=> => writing image sha256:2581a16d6683a60685240853568b0f8f1ce58b2829dc6f2b98a78dfef5b1ca 0.0s
=> => naming to docker.io/ethyca/fidesctl:local 0.0s |
yeah that seems kinda weird... oh well, sounds like this PR will just be some tinkering around stream-lining whatever parts of the build that we can, specifically for |
Here's mine after
|
I never noticed this before but since we started looking at this I see you can tell if the layer used cache if it starts with |
1.8s doesn't seem like enough time to actually install all of those modules? there's some kind of black magic cache going on or something 😂 i don't know how else that can be possible |
@allisonking I'm going to defer on this one until you finish up the frontend packaging PR since I don't want to potentially create conflicts |
@NevilleS fixed this 🚀 |
Is your feature request related to a specific problem?
nox -s dev
takes a really long time....this appears to be primarily due to the fact thatnpm install
step isn't getting cached asnode_modules/
is included in the.dockerignore
fileDescribe the solution you'd like
For the sake of development, we should find a way to cache or use locally installed npm modules to majorly cut down on the time needed to spin up
nox -s dev
Describe alternatives you've considered, if any
Not sure what other options might exist yet
Additional context
N/A
The text was updated successfully, but these errors were encountered: