-
Notifications
You must be signed in to change notification settings - Fork 136
[release/2.1] Detect package cache blocking source-built package uptake #711
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
Conversation
Detect when a source-built package exists, but a different package exists in the package cache directory. NuGet restore short-circuits when the package id/version specified is already in the cache, so the source-built one won't be used by downstream repos.
repos/dir.targets
Outdated
@@ -334,6 +344,8 @@ | |||
<PrebuiltPackages Include="$(PrebuiltPackagesPath)*.nupkg" /> | |||
<PrebuiltPackages Include="$(TarballPrebuiltPackagesPath)*.nupkg" Condition="'$(TarballPrebuiltPackagesPath)' != ''"/> | |||
|
|||
<PrebuiltPackages Include="$(CustomUsageCheckPackageDir)*.nupkg" Condition="'$(CustomUsageCheckPackageDir)' != ''" /> |
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.
I don't get what's happening with CustomUsageCheckPackageDir here.
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.
Ah, yeah, this is kind of out of nowhere here. I'll add a comment. The idea is it's used by FindSourceBuiltUsages
to do a "custom usage check".
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.
I see that, but why is it included in PrebuiltPackages?
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.
Heh, good point... I was being lazy and using the existing target without much modification just out of convenience. I'll reorganize this to make sense.
I'll also try to make it run immediately after it detects the problem and focus the report the specific problematic package(s). If you just do what the message suggests and run this after the build completes, there's too much junk to practically sift through.
Now it outputs this in this situation (for every project after the place this problem was introduced):
{
"UnusedPackages": [],
"Usages": [
{
"ProjectDirectory": "/home/dagood/sb/source-build/src/common",
"AssetsFile": "/home/dagood/sb/source-build/src/common/test/Microsoft.Extensions.CommandLineUtils.Tests/obj/project.assets.json",
"PackageIdentity": "Newtonsoft.Json/9.0.1",
"Annotation": null
}
]
} It does this for every project, since I think it's ok to let the build continue (in this case, at least), and I think it could be interesting to look at each later project's usages (if any). |
@dotnet-bot test OSX10.12 Release |
Interesting, the conflict doesn't happen in the offline tarball build. |
Detect when a source-built package exists, but a different package exists in the package cache directory. NuGet restore short-circuits when the package id/version specified is already in the cache, so the source-built one won't be used by downstream repos.
This is for #606.
It actually spots an active problem in this branch (
release/2.1
):I checked to make sure contents of the package cache are really from online. Related (although I don't think we realized the extent of the issue): #593.