-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Dependencies are still installed after cache flag is true #349
Comments
Hello @gabrielmoncea. Thank you for your report. Global cache directory is used for caching in setup-node. For yarn you can check cache directory by this command: |
@dmitry-shibanov thanks. It means that I understood the docs wrong. It seemed to me that it applies the cache if detected |
You're welcome @gabrielmoncea. For more details please check section Caching packages dependencies in the Advanced usage guide. I'm going to close the issue. Feel free to contact us if you have any questions. |
Hi @dmitry-shibanov -- thanks so much to you and the team for the awesome work on this tool!
For anyone running across this later: In our case, the problem was because caching is per-branch. We were using this in a PR flow, so the first run on a new PR branch was not using the cache. Subsequent runs on the same branch do cache as expected |
Hello @rcb4t2. Thank you. The setup-node action does not have restore keys. If primary key (generated by yarn.lock file) is changed, the action will resave cache and it won't restore it. Besides, the speed depends on the size of the project. If it does not have a lot of dependencies, you won't get a big speed up. |
Thanks for the reply, @dmitry-shibanov ! After examining our logs more carefully, I realized that your Action is properly restoring from cache as long as the 2nd run is on the same branch. We do see a speed improvement for yarn install from about 70 seconds to around 30s, which is plenty for our purposes. We are already using (PS: do you have a support forum or email link for general questions? I don't want to pollute your issue queue) |
Commenting on this closed issue because it's highly relevant. I still don't understand this thing (my fault I'm sure). described here. When I create my own cache action to cache node_modules and then run
and it takes 3 seconds. But when I use this action's
What am I misunderstanding? Maybe a documentation issue could clear this up (maybe just pointing me to the right lines in the docs/yarn docs)? |
Hello @akmjenkins. According to the documentation the action setup-node caches global cache. It does not cache |
@dmitry-shibanov thank you but I'm still confused. So I assume it caches node images that it downloads, but why do we specify a cache option of The line in the documentation I really appreciate your response! |
Hello @akmjenkins. Hosted images have precached versions of Nodejs. If version does not exist on the image, it will be downloaded and precached. If you use self-hosted runners Nodejs versions will be saved. Hosted runners are cleaned at the end of the job, so saved nodejs versions won't be saved for future runs.
|
AHHHH, now I got it. This is why it still takes 40 seconds or so. The modules are all cached (when I specified Thank you so much for spelling this out for me 🙏🏼 🙏🏼 🙏🏼 |
Description:
Yarn still installs dependencies even though cache flag is true.
Tested on hosted ubuntu-latest env and on self-hosted macOS env.
Action version:
Specify the action version
actions/checkout@v2
Platform:
Runner type:
Tools version:
yarn v1.22.15
Repro steps:
A description with steps to reproduce the issue. If your have a public example or repo to share, please provide the link.
Expected behavior:
After cache is applied yarn install should be skipped.
Actual behavior:
After cache is applied yarn installs dependencies
.
The text was updated successfully, but these errors were encountered: