Implement basic NuGet cache purging #58
Merged
Conversation
This file contains 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
runesoerensen
changed the title
runesoerensen
force-pushed
the
purge-nuget-cache
branch
from
b8afbbc to
a8a6892
Compare
runesoerensen
force-pushed
the
purge-nuget-cache
branch
from
a8a6892 to
c52eb51
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 PR adds support for purging the NuGet cache layer after a number of restores (largely inspired by the yarn buildpack implementation). The max number of restores need to be adjusted (from 10) based on a number of factors -- especially when support for more granular per-package purging (as described in #15) is implemented.
However, seeing as NuGet package caches can grow quite a bit over time, we'll likely always want to have a hard layer restore limit count, if only to account for scenarios where other approaches do not purge the cache as expected.