CI: Cache/restore the npm network/package cache#43
Closed
DeeDeeG wants to merge 3 commits intoalways_restore_cachefrom
Closed
CI: Cache/restore the npm network/package cache#43DeeDeeG wants to merge 3 commits intoalways_restore_cachefrom
DeeDeeG wants to merge 3 commits intoalways_restore_cachefrom
Conversation
aminya
force-pushed
the
always_restore_cache
branch
from
e1929b3 to
6805390
Compare
aminya
force-pushed
the
always_restore_cache_plus_npm
branch
from
861ded2 to
e1e2c0b
Compare
Member
Author
|
For the historical record: to the best of my knowledge, this PR was at commit 861ded2 before #46 was merged into For convenience (and to keep that commit and its parents from being pruned), this branch exists to mark said commit, at least for now: |
Member
Author
|
I'm not sure this had any benefit. I think we can close? @aminya if you don't mind I say we should close this. |
Member
|
Let's wait until we merge #50. I want to test and see if any time is saved. |
aminya
force-pushed
the
always_restore_cache
branch
from
6805390 to
06306b0
Compare
aminya
force-pushed
the
always_restore_cache
branch
from
06306b0 to
cd3a463
Compare
This saves/restores the caches of just the packages as source code. Not the installed and/or compiled versions, which are in node_modules. (We have already been caching those for some time now.) Co-Authored-By: deedeeg <deedeeg@users.noreply.github.com>
No need to "save time on network access" if there won't be any network access at all! Co-Authored-By: deedeeg <deedeeg@users.noreply.github.com>
aminya
force-pushed
the
always_restore_cache_plus_npm
branch
from
e1e2c0b to
ee770ef
Compare
DeeDeeG
force-pushed
the
always_restore_cache
branch
from
c1f57f2 to
72c1d79
Compare
Member
|
This does not seem to have any benefits. I will close this. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This saves/restores the caches of just the packages.
(Not the installed and/or compiled versions, which are in node_modules;
We have already been caching those for some time now.)
Requirements for Adding, Changing, or Removing a Feature
Requirements for Adding, Changing, or Removing a Feature
Issue or RFC Endorsed by Atom's Maintainers
Discussed here: #33 (comment)
Description of the Change
Cache not only the post-install
node_modulesfolder, which we have been caching for some time now, but also the pre-install package/network cache thatnpmstores the packages from the registry in. This cache is there so you don't have to wait for your network connection to the registry, but can pull previously fetched packages straight from the hard disk.In this case, caching it moves the network hit to "somewhere else in the Azure DevOps servers", which should hopefully be faster than hitting the npm registry.
Alternate Designs
Don't do this, and keep doing what we've been doing.
I'm trying this because I want to see if it is, in fact, faster. It's an experiment.
Possible Drawbacks
Could be slower than just hitting the npm package registry.
Or this could somehow be unreliable or add undesirable complexity. However, the
Cache@2task is very well-behaved, being more likely to gracefully step out of the way and not do anything if it can't fully restore a cache. And npm fairly heavily validates everything that goes into/come out of the cache. So hopefully there's no issue with keeping the network/package cache around for multiple runs.Verification Process
Watch CI and see what happens.
Release Notes
N/A