-
-
Notifications
You must be signed in to change notification settings - Fork 171
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
Make GitPackCache include ObjectType #942
Conversation
Otherwise, we would have I/O operations for every request for a wrong objectType. By having it as part of the value we can use the cache and aquire the information that the objectType does not match from the cache.
3e57658
to
820e843
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks fantastic! Thank you.
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
Sorry it took so long for me to get to this, @georg-jung. |
So weird.... I've re-queued the build 3 times and the test process crashes every time. Yet several other builds today passed the first time, so there seems to be something uniquely about this PR that causes a test crash, but it sure seems safe enough. I'm still looking into it. |
Thanks for taking a look! Back then, my pipeline ran. I started a run on my ADO on this PR's branch here: https://dev.azure.com/georg-jung/Nerdbank.GitVersioning/_build/results?buildId=1871&view=results I also rebased the PR's contents in a second branch to be on-par with latest main and started a run on it too: https://dev.azure.com/georg-jung/Nerdbank.GitVersioning/_build/results?buildId=1872&view=results Both are still in progress as of writing. (Well the pipeline did/does fail, but that's because it can't publish packages to your CI feed; the tests ran successfully) |
All the test steps seem to work in my ADO, for the rebased version as well as the original one. Really strange. |
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
See #876 (comment)
This adds caching of the determined objectType alongside the object's content. While the approach in d0aa014 seems a bit more straight forward than the one in fafa498, I think it is preferrable to have the contentType as part of the cached value instead of the cache key. Otherwise, repeated requests with a mismatching objectType will not profit from caching.
I thought about adding proper
TryGetObject
implementations as part of this. This turned out to be quite hard to get right though. The topics aren't too closely related too so I think they work as seperate PRs. Because these cache improvements should be sufficient to make #876 work, I decided to split this up and postpone the properTryGetObject
implementations.