-
Notifications
You must be signed in to change notification settings - Fork 632
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
ci: Cache nuget packages (Github actions) #866
base: master
Are you sure you want to change the base?
Conversation
Thanks for the PR. One issue we had when we tried this on Azure DevOps was it wasn't set up right to correctly detect an upgrade or change of a dependency and when we did a "normal" upgrade of a dependency it failed. The only way I found out of that scenario was to remove the caching and add an explicit download location in NuGet.config. I have read somewhere that packages.lock.json isn't consistently generated across machines, which makes them change too often to keep in source control because they show up as changed files even when no dependencies have changes. Also, having these extra files seems a bit odd when we have a dependencies.props file that can be used as part of the cache key (we would also need to include all *.csproj and all *.targets files to get all of the references). Whatever the case, we need a solid procedure for upgrading or changing dependencies so we don't shoot ourselves in the foot (again) when upgrading. We are likely going to be juggling dependencies around more often from now until the release than we have done so in the past. If we stick with the packages.lock.json files, it would be nice to know how to update them and when to commit them. |
Hey @NightOwl888 I've used The Does this answer you questions? |
Actually, what I am looking for is a step-by-step procedure for updating a dependency and making sure the cache gets invalidated so the new dependency version is used. The blog article about it makes it clear what the Do note that we have a condition on the My guess is the procedure is something along the lines of:
Putting the procedure here is okay, but ideally we would add it to a new page in the contrbuting section. And when Azure DevOps has caching we can add those instructions there as well (if we use The My hope is to have this whole procedure tested out prior to running it, since there is no way (at least in Azure DevOps) to invalidate the cache. The only option is to give the key a different name (which I know now, but didn't know then). It was a major showstopper having the cache put in place on Azure DevOps without it detecting when there was a change to the dependencies and then having to try to figure out how to work around the problem. We ended up having to remove the cache and then add a |
closes #857
This adds a cache step to the GitHub actions using
packages.lock.json
files. These files are generated on build and keep track of changes in the dependencies of projects. Thereby acting as cache keys. I've also added thedotnet restore
step separately from the build and pack steps so that it's easier to see how much time is spent on restoring vs building in an action.