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
Do not ivalidate the cache entirely on lock file change #744
Conversation
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.
From the code standpoint it looks ok to me. I am not sure about the semantics :)
8e8ef76
to
408539a
Compare
8d52008
to
70c9389
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.
Looks good to me
I'll keep my green light. Couldn't find something out of order, still looks good to me. But don't forget to rename branch from |
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.
LGTM!
5c6f97e
to
22005da
Compare
3a690c3
to
71e53d3
Compare
b4911ac
to
d583854
Compare
Hey thanks ! a small question Does it disable the node_modules folder caching when yarn3 zip files are enabled ? |
Hello @belgattitude, the PR does not change the caching strategy in part of node_modules folder, but yarn3 replaces node_modules with PnP that is supposed to be managed through VCS |
Hey - I'm trying to understand this change. Does it mean that the best thing a Yarn project running with this action can do is to NOT use the global cache ( In Yarn v4 we're changing the default to make |
Ping @dsame ? We'll soon release the 4.0 stable; do we need to automatically set |
Personally I wouldn't. The enableGlobalCache new default won't be enough to get the benefits (action cache keys are part of the recipe too). I would let the setup responsability to setup/node or any tool/action/script that help setting up caches. Applying different defaults depending on env might also create confusion. I'd prefer a section in the yarn doc that focuses on a simple recipe for ci and caches (possibly with less emphasis on offline mode or a reference to it as an advanced use case.). That would help people implementing cache strategies (azure, vercel... ) to identify quickly what variables are important, what they do and apply a strategy within their "platform" possibilities. Congrats for Yarn 4.0 |
Hello @arcanis!
Yes, if the user uses the local cache and
Thank you for contacting us and letting us know, we really appreciate it! In our opinion, it is not necessary to leave |
@arcanis for context, I realized there was a thread about the new setup node cache. It starts from there #325 (comment) |
Description:
Add a function
cache-utils.ts:repoHasYarn3ManagedCache
returnstrue
if there's at least one project with yarn3 managed cacheYarn3 managed cache enables safe use of the previous cache
cache.restoreCache(cachePaths, primaryKey, [keyPrefix])
because obsolete dependences are removed by Yarn not letting cache to grow endlessly
Related issue:
#325
The PR initially contained Node version in the key but it was removed due to
#325 (comment)
Check list: