CI failure in the "banana" rid leg on Centos Stream 8

[jkoritzinsky]

We're seeing a failure on the banana leg where we use a fake RID that isn't in the RID graph. The RID graph construction tools look like they are unable to determine where to add the banana.24-x64 RID into the RID graph. I think this is new with the CentOS Stream 8 base image change, but there have been many different failures in this leg for a while that I'm not sure what caused it to start failing in this manner.

Known Issue Error Message

Fill the error message using known issues guidance.

{
  "ErrorMessage": "",
  "BuildRetry": false
}

Report

Summary

24-Hour Hit Count	7-Day Hit Count	1-Month Count
0	0	0

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

Issue Details

---

We're seeing a failure on the banana leg where we use a fake RID that isn't in the RID graph. The RID graph construction tools look like they are unable to determine where to add the banana.24-x64 RID into the RID graph. I think this is new with the CentOS Stream 8 base image change, but there have been many different failures in this leg for a while that I'm not sure what caused it to start failing in this manner.

Known Issue Error Message

Fill the error message using known issues guidance.

{
  "ErrorMessage": "",
  "BuildRetry": false
}

Author:	jkoritzinsky
Assignees:	-
Labels:	area-Infrastructure-libraries, blocking-clean-ci, source-build, untriaged
Milestone:	-

[ViktorHofer]

cc @am11 @tmds

[ViktorHofer]

@jkoritzinsky can you please link to a build?

[jkoritzinsky]

https://dev.azure.com/dnceng-public/public/_build/results?buildId=271423&view=logs&j=7b858ce4-c6ea-5e44-1ed3-07363cd3c838

[ViktorHofer]

@tmat would you mind looking at the build and trying to diagnose what's failing? Asking as you recently made changes to the GenerateRuntimeGraph task.

[ericstj]

For brand new RIDs you should also specify AdditionalRuntimeIdentifierParent with something like linux or rhel or whatever is appropriate. Looks like folks try to handle here:

runtime/eng/SourceBuild.props

Line 43 in ce689d9

<InnerBuildArgs>$(InnerBuildArgs) /p:AdditionalRuntimeIdentifierParent=$(BaseOS)</InnerBuildArgs>

. Not sure if that's being used in the scenario discussed here.

[ericstj]

@ViktorHofer did you mean to tag @tmds rather than @tmat?

[jkoritzinsky]

That was never in use when this job was run on CentOS 7, so I wasn't sure if the BaseOS was inferred from somewhere or if it was broken there already.

There's no good way to specify the BaseOS (or any other additional properties for that matter) in the eng/common infra for source-build, so we might need to solve that problem first.

[tmds]

Sorry for chiming in late. As mentioned, we should set the BaseOS (just like source-build does). I'll make a PR for it.