Source Build Validation legs are failing

[am11]

Source-Build (CentOS9) is failing with:

https://dev.azure.com/dnceng-public/public/_build/results?buildId=1021233&view=logs&jobId=46d4bc78-82b7-5486-55ce-7714ebdf0ac0&j=527da66b-556b-54bb-107f-cdc8a55a2854&t=255f8d3e-16e8-5d6d-908e-7cc01450d912

    Determining projects to restore...
    Restored /__w/1/s/artifacts/sb/package-cache/microsoft.dotnet.arcade.sdk/10.0.0-beta.25216.2/tools/Tools.proj (in 10.25 sec).
    Determining projects to restore...
  /__w/1/s/.dotnet/sdk/10.0.100-preview.3.25201.16/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(108,5): error NETSDK1083: The specified RuntimeIdentifier 'centos.9-x64' is not recognized. See https://aka.ms/netsdk1083 for more information. [/__w/1/s/artifacts/sb/src/Build.proj]
  /__w/1/s/.dotnet/sdk/10.0.100-preview.3.25201.16/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(108,5): error NETSDK1203: Ahead-of-time compilation is not supported for the target runtime identifier 'centos.9-x64'. [/__w/1/s/artifacts/sb/src/Build.proj]
  /__w/1/s/.dotnet/sdk/10.0.100-preview.3.25201.16/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(108,5): error NETSDK1083: The specified RuntimeIdentifier 'centos.9-x64' is not recognized. See https://aka.ms/netsdk1083 for more information. [/__w/1/s/artifacts/sb/src/Build.proj]
  /__w/1/s/.dotnet/sdk/10.0.100-preview.3.25201.16/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(108,5): error NETSDK1203: Ahead-of-time compilation is not supported for the target runtime identifier 'centos.9-x64'. [/__w/1/s/artifacts/sb/src/Build.proj]
    Nothing to do. None of the projects specified contain packages to restore.

and Source-Build (NonexistentRID) - the purpose of this one is to validate that we don't take a dependency on non-portable RID's value and distro maintainer is free to choose the identifier prefix:

https://dev.azure.com/dnceng-public/public/_build/results?buildId=1021233&view=logs&jobId=46d4bc78-82b7-5486-55ce-7714ebdf0ac0&j=46d4bc78-82b7-5486-55ce-7714ebdf0ac0&t=5940e102-b135-58b6-71a4-2593b90abf9d

    Determining projects to restore...
    Restored /__w/1/s/artifacts/sb/package-cache/microsoft.dotnet.arcade.sdk/10.0.0-beta.25216.2/tools/Tools.proj (in 10.83 sec).
    Determining projects to restore...
  /__w/1/s/.dotnet/sdk/10.0.100-preview.3.25201.16/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(108,5): error NETSDK1203: Ahead-of-time compilation is not supported for the target runtime identifier 'linux'. [/__w/1/s/artifacts/sb/src/Build.proj]
  /__w/1/s/.dotnet/sdk/10.0.100-preview.3.25201.16/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(108,5): error NETSDK1203: Ahead-of-time compilation is not supported for the target runtime identifier 'linux'. [/__w/1/s/artifacts/sb/src/Build.proj]
    Nothing to do. None of the projects specified contain packages to restore.

cc @jkoritzinsky, @tmds, last time they appeared passing was in December, then three months logs are missing and since then, all red: https://dev.azure.com/dnceng-public/public/_build?definitionId=129&_a=summary&branchFilter=331%2C331%2C331
it's the second circle:

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

[akoeplinger]

FYI we'll be removing these legs soon: dotnet/source-build#5021

[tmds]

Our internal CI shows this as well across all .NET 10.0 jobs.

Build of April 13th (27b2548) was working, build of April 15 fails (b0c2d75).

It probably regressed in #113765.

cc @jkoritzinsky @ViktorHofer

[tmds]

cc @omajid

[am11]

FYI we'll be removing these legs soon: dotnet/source-build#5021

It would be best to add their coverage to VMR before removing them from runtime. i.e. dotnet/source-build#4918 then dotnet/source-build#5021.

I think the ultimate test for RID agnostic-ness is NonexistentRID, if we can make it green we can be confident that there is no unintended inference from RID in the code. 🙂

[tmds]

I think the ultimate test for RID agnostic-ness is NonexistentRID, if we can make it green we can be confident that there is no unintended inference from RID in the code.

👍

In our internal CI we have a test that build the vmr with some random target rid (that doesn't match /etc/os-release). Then we take those assets to another system (which rid matches neither the initial system nor the target rid) and use them for a non-portable build.

[ViktorHofer]

@tmds would you mind filing an issue at https://github.com/dotnet/source-build to track adding a validation job that verifies that the VMR can be built with a random banana target rid?

[tmds]

It probably regressed in #113765.

With these changes, BaseOS gets used instead of PackageRID. This means it is required to pass BaseOS for non-portable builds to work. We are not doing this in our CI, and perhaps the CI legs that fail here are not doing it either.

src/libraries/System.Runtime.InteropServices/tests/TestAssets/NativeExports/NativeExports.csproj is missing the part that causes non-portable builds to use BaseOS for restore:

<AppHostRuntimeIdentifier Condition="'$(OutputRID)' != '$(NETCoreSdkRuntimeIdentifier)' and '$(BaseOS)' != '' ">$(BaseOS)</AppHostRuntimeIdentifier>

@ViktorHofer @jkoritzinsky should I make a PR to add this? When #114285 is merged, it is no longer needed.

[tmds]

@tmds would you mind filing an issue at https://github.com/dotnet/source-build to track adding a validation job that verifies that the VMR can be built with a random banana target rid?

I thought about this.

Previously .NET rids were determined at runtime from /etc/os-release while for recent versions the rid gets fixed at build time (TargetRid). All non-portable builds we do now are building an "unknown rid" (since the rid isn't part of Microsoft's portable SDKs).

If we mix up the Target RID with the build SDK RID in some places, cross-build CI will pick that up.

As a result, I think we have good coverage already with the vmr CI that is in place.

I assume this issue isn't picked up by that CI because it is in a tests project that the vmr doesn't restore.