NightOwl888 commented on PR #866: URL: https://github.com/apache/lucenenet/pull/866#issuecomment-3245961855
>I think that will be fine since our dependencies do not change very frequently. "Frequently" is a relative term. We review them every time we release and often bump versions and add or remove packages several times between releases. I don't object to caching, but there must be some consideration given both to: 1. Whether it changes our development workflow, and if it does, we need documentation so we can upgrade painlessly. 2. It must be confirmed to allow us to update dependencies before it is rolled out. The second issue bit us hard the first time around because the `dependencies.props` file wasn't included in the cache key, which is the main file that we change to bump/add/remove dependencies. So when trying to build after upgrading a package, it broke in a way that was unrecoverable because the cache is permanent. We worked around it by turning the cache back off again and adding a `NuGet.config` file (which seemed to be required due to the cache blocking downloads somehow). I like the idea of using a cache key that we don't have to think about, which would have been the case had the `dependencies.props` and all other `.props`, `.targets`, `.msbuildproj` and other MSBuild files been included instead of only including the `.csproj` files. I tried to add them after the fact, but as I mentioned, once the cache key is set there is no way to change it (on Azure DevOps, anyway). I found out much later after disabling the caching that it could have been worked around by changing the name of the cache, but it wasn't obvious at the time when I was deperate to get a build to function so I could roll a release (and that was before AI chatbots were a thing). -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
