Lengthy RuntimeIdentifierGraph update roundtrip with SDK

[am11]

A change to src/libraries/pkg/Microsoft.NETCore.Platforms/runtime.json requires a full update cycle, which includes:

1. a PR updating runtime.json merged in runtime repo
2. SDK repo picks up runtime change
3. runtime picks up the updated SDK

This blocks building CLR tests on a new platform, until all of the above has happened (or we patch SDK after the restore). For example, my current workaround is:

# workaround: overwrite file containing updated RIDs from libraries
/runtime $ cp src/libraries/pkg/Microsoft.NETCore.Platforms/runtime.json \
    .dotnet/sdk/5.0.100-preview.6.20310.4/RuntimeIdentifierGraph.json

# then cross-compile CLR tests without getting restore errors
/runtime $ ROOTFS_DIR=$(pwd)/.tools/rootfs/x64 ./src/coreclr/build-test.sh \
    -x64 -cross -os illumos -gcc

In the age of live-live builds, is it possible to ensure LiveRuntimeIdentifierGraphPath from eng/liveBuilds.targets is properly picked up during the SDK resolution for test build? Currently it seem to have no effect (despite being imported in src/coreclr/tests/src/Common/test_dependencies/test_dependencies.csproj) and SDK ends up using .dotnet/sdk/<version>/RuntimeIdentifierGraph.json, instead of the runtime.json file pointed by LiveRuntimeIdentifierGraphPath.

cc @jashook, @jkotas

Tagging subscribers to this area: @safern, @ViktorHofer
Notify danmosemsft if you want to be subscribed.

[am11]

I think the previous tag was correct; this was only encountered during the build of CLR tests.

[jkotas]

The fundamental problem is the process required to add new RIDs that falls under libraries though.

[ViktorHofer]

In the age of live-live builds, is it possible to ensure LiveRuntimeIdentifierGraphPath from eng/liveBuilds.targets is properly picked up during the SDK resolution for test build?

I don't know how flowing of the RID graph into the SDK currently works. I assumed this is handled by the Microsoft.NetCore.Platforms OOB package so I'm wondering how the SDK comes into play here. @ericstj might know.

[jkoritzinsky]

To my knowledge dotnet/installer pulls down the Microsoft.NETCore.Platforms package during build and embeds the file in the final product.

[ericstj]

Seems like the SDK just needs a place to define this. Let's see if they have it. /cc @dsplaisted

[dsplaisted]

You can set the BundledRuntimeIdentifierGraphFile property to the path to the updated runtime identifier graph json file. Is that what you're looking for?

[am11]

I think RuntimeIdentifierGraphPath is the way to define custom path, which SDK checks here, and liveBuilds.targets defines at:

runtime/eng/liveBuilds.targets

Line 202 in c19ce52

<RuntimeIdentifierGraphPath Condition="'$(UseLiveRuntimeIdentifierGraph)' == 'true'">$(LiveRuntimeIdentifierGraphPath)</RuntimeIdentifierGraphPath>

For some reason it is not taking effect when this targets is imported by Directory.Build.targets at repo root. (it is already too late by then?)

Before the cp workaround mentioned above, I was getting:

/runtime/.dotnet/sdk/5.0.100-preview.6.20310.4/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(59,5): error NETSDK1083: The specified RuntimeIdentifier 'illumos-x64' is not recognized. [/runtime/src/coreclr/tests/src/Common/test_dependencies/test_dependencies.csproj] [/runtime/src/coreclr/tests/build.proj]
/runtime/src/coreclr/tests/build.proj(52,5): error MSB3073: The command ""/runtime/.dotnet/dotnet" restore -r illumos-x64 /runtime/src/coreclr/tests/src/Common/test_dependencies/test_dependencies.csproj  /p:SetTFMForRestore=true /p:TargetOS=illumos /p:TargetArchitecture=x64 /p:Configuration=Debug " exited with code 1.

[ericstj]

@am11 it looks like you need to set the property @dsplaisted mentions (BundledRuntimeIdentifierGraphFile) it seems to get used in a few more places than RuntimeIdentifierGraphPath: https://github.com/dotnet/sdk/search?q=BundledRuntimeIdentifierGraphFile&unscoped_q=BundledRuntimeIdentifierGraphFile