NightOwl888 commented on PR #866: URL: https://github.com/apache/lucenenet/pull/866#issuecomment-1755518186
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](https://devblogs.microsoft.com/nuget/enable-repeatable-package-restores-using-a-lock-file/) makes it clear what the `packages.lock.json` file is for and how to configure it, but not how to perform a dependency update (which is the important bit). Of course, without 3rd party docs this might boil down to doing experimentation. Do note that we have [a condition on the `ContinuousIntegrationBuild` property](https://github.com/apache/lucenenet/blob/51cc7418adf9da96cd37dd64ff5085d752a54074/Directory.Build.props#L81-L83) so it only is set to true in Azure DevOps and GitHub Actions. This property is also used by the [Source Link](https://lucenenet.apache.org/docs/4.8.0-beta00016/api/core/source-stepping.html) functionality and that is the way they recommended to use it. My guess is the procedure is something along the lines of: 1. Update the dependencies 2. Run the build (in VS? on the command line?) 3. Check the diff of the `packages.lock.json` files for any issues 4. Commit the changes to Git 5. Validate the changes worked in GitHub Actions 6. And after the functionality has been added...validate the changes worked in Azure DevOps Putting the procedure here is okay, but ideally we would add it to a new page in the [contrbuting](https://lucenenet.apache.org/contributing/index.html) section. And when Azure DevOps has caching we can add those instructions there as well (if we use `packages.lock.json` chances are there will be some overlap in the procedures). The `packages.lock.json` being flakey may have been due to early buggy build tools that have now been fixed, not sure. I think there were differences in the way the lock file was generated on the command line vs the IDE at some point. At least [this article](https://blog.inedo.com/nuget/manage-dependencies-lockfiles-package-consumers/) recommends using a lock file but also goes into some of the issues with doing so. 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 `NuGet.config` because for some reason it was no longer looking in NuGet.org for the dependencies. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@lucenenet.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
