-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Move BuildRID lists to common props #55279
Conversation
I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label. |
68cc90f
to
52e4a40
Compare
d093d23
to
56ee8e3
Compare
Remaining failures are unrelated to the change (NuGet hangups, EventSource test failures). Marking it as ready for review. |
56ee8e3
to
e393b6a
Compare
e393b6a
to
9078645
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 reasonable to me, but I would like either @hoyosjs or @jkoritzinsky to take another look as well.
Also, do we need to test this in an official build?
I'll review and kick off an internal build. We should also test this for sourcebuild. |
Thanks. There was a redundant exclusion I have just deleted (it won't change the outcome since RestoreBuildRID is used in a place where ExcludeFromBuildRID is not set). |
@hoyosjs, was the internal build green?
I can see |
I did a manual check with non-portable rids for sourcebuild and all looked ok. I also code reviewed and it looks fine. I kicked off one and will report when I see it finish. |
Looks like there are some repeated assets.
|
Can we run that target locally or is it something only run on official build? If there is no secure argument involved please paste the command, I can try to investigate it locally. |
It means that two different legs produced it. Currently trying to see which two legs produced the same package. |
Looks like The command line for the libraries
And for the allsubsets one:
Another difference, we are now suddenly producing these that we weren't:
|
@@ -4,7 +4,7 @@ | |||
<SkipPackageFileCheck>true</SkipPackageFileCheck> | |||
<SkipValidatePackage>true</SkipValidatePackage> | |||
</PropertyGroup> | |||
<ItemGroup Condition="'$(PackageTargetRuntime)' == 'linux-arm' or '$(PackageTargetRuntime)' == 'linux-arm64' or '$(PackageTargetRuntime)' == 'linux-x64' or '$(PackageTargetRuntime)' == 'osx-x64' or '$(PackageTargetRuntime)' == 'freebsd-x64'"> | |||
<ItemGroup Condition="'$(PackageTargetRuntime)' != '' and !$(PackageTargetRuntime.ToLowerInvariant.StartsWith('win'))"> |
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.
This somehow didn't consider ARM64 before. It also now considers linux-musl variants when it didn't before.
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.
ARM64 is present before and after the change. linux-musl is not (that restriction does not seem intentional either). I think this is not causing the validation error. I think the issue is that we have three ways of including pkgproj, one from src/libraries/libraries-packages, one from .proj file and then again from Directory.Build.props. We should try to simplify it, so transition to SDK/dotnet-pack in future become easier.
In this PR, I have changed complex whitelisting to "require a flat list and exclude" mechanism.
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.
osx-arm64 I mean
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 am not saying I am against it. I am just saying we might start seeing assets we didn't see before. I'll all for a single list of support and then projects that need can opt out.
</OfficialBuildRID> | ||
</ItemGroup> | ||
<ItemGroup Condition="$(SupportedPackageOSGroups.Contains(';OSX;'))"> | ||
<OfficialBuildRID Include="osx-x64" /> |
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.
Probably this is why we didn't have arm64 ILAsm
41247ad
to
7e03c4c
Compare
I still see some manifest differences. I'll try later. |
I checked this again and the following packages are missing now compared to tip of main:
but they are referenced by the metapackage runtime.native.System.IO.Ports, and a bunch of unofficial rids that we don't produce packages for: Meanwhile this is the dep list for the one in main: This would probably break things. Also @ericstj not sure who owns ports, but shouldn't the package also exist in main for ARM64 osx? Although to be fair, the musl variants seem not to have one so it might be OK? |
Lets start it at some other point, since I don't have time to further work on it. Changing one flag breaks some superfluous check somewhere which we can't locally reproduce, seems like we first need to fix CI to cover all sanity checks before doing refactoring. |
Yeah, this is pretty sad. But there's some place where things are more coupled than we realize. In this case the official build even was green and so was CI - so we are even missing some deeper validation. |
as far as I remember we did the extra IO.Ports packages so one can consume them on older versions. While consistency is nice I'm not sure there is real demand since the Serial port is not available for quite a while and it should work when used with current runtime. In some cases like ARM macOS the older versions did not even function on that platform. |
It seems to be used on all frameworks, unix runtimes today, which would include OSX ARM64: runtime/src/libraries/System.IO.Ports/src/System.IO.Ports.csproj Lines 116 to 119 in b056b7b
It'd be great if that could be removed on latest frameworks. |
@am11 Tizen/armel build is still broken. If you don't mind, could I make a new PR to fix Tizen/armel crossgen2 issue based on this PR? |
Platform matrix testing is in progress, but locally made sure that the
artifacts/package
directory tree on macOS is identical before and after this change.This PR is simplifying the BuildRID part. It removes
OfficialBuildRID
andUnofficialBuildRID
(not to be confused with very similar-lookingOfficialBuildID
which is a contract between runtime and arcade for versioning). Also fixes tizen/armel crossgen2 issue at the same time.cc @ViktorHofer