Update CentOS version -- release/8.0.1xx

[richlander]

No description provided.

[marcpopMSFT]

@richlander I think I remember in chat that @MichaelSimons mentioned something about the runtime builds needing to change first but I couldn't find it in Teams. Currently the centos leg is failing to find the runtime version that matches. Has the runtime been updated and do we need to wait until the version in GH updates?

[richlander]

Good point. I don't know the specifics. Can you log a tracking bug in runtime @MichaelSimons?

[MichaelSimons]

Good point. I don't know the specifics. Can you log a tracking bug in runtime @MichaelSimons?

I updated the branch because the last build was removed and I need to refresh my memory on what exactly is needed from runtime.

[nagilson]

Should we merge these?

[richlander]

@MichaelSimons -- This is why we need better SB docs. There is significant ambiguity on this thread. It should all be clear as day in docs. It's unclear to me if the SB or runtime team has these answers.

dotnet/source-build#4890

[richlander]

Yes.

Min CentOS Stream versions by .NET version / branch:

• .NET 8/9: Stream 9
• .NET 10: Stream 10

dotnet/sdk#46721

[MichaelSimons]

@MichaelSimons -- This is why we need better SB docs. There is significant ambiguity on this thread. It should all be clear as day in docs. It's unclear to me if the SB or runtime team has these answers.

dotnet/source-build#4890

I'm not seeing how SB docs are going to clear up anything related to this PR. The primary changes here are updating the installer's CI/PR legs.

[richlander]

I likely had an incorrect notion. I thought that this repo was using CentOS Stream due to source build.

Also, why are we building this repo so many times? It would be good to see this choice covered.

Who is a good person to document the process and these design decisions?

installer/.vsts-ci.yml

Lines 46 to 65 in 4b46c44

	extends:
	template: v1/1ES.Official.PipelineTemplate.yml@1esPipelines
	parameters:
	containers:
	alpine319WithNode:
	image: mcr.microsoft.com/dotnet-buildtools/prereqs:alpine-3.19-WithNode
	cblMariner20Fpm:
	image: mcr.microsoft.com/dotnet-buildtools/prereqs:cbl-mariner-2.0-fpm
	centosStream9:
	image: mcr.microsoft.com/dotnet-buildtools/prereqs:centos-stream9
	debian11:
	image: mcr.microsoft.com/dotnet-buildtools/prereqs:debian-11-amd64
	fedora40:
	image: mcr.microsoft.com/dotnet-buildtools/prereqs:fedora-40
	ubuntu2204:
	image: mcr.microsoft.com/dotnet-buildtools/prereqs:ubuntu-22.04
	mariner20CrossArm:
	image: mcr.microsoft.com/dotnet-buildtools/prereqs:cbl-mariner-2.0-cross-arm-alpine
	ubuntu2204DebPkg:
	image: mcr.microsoft.com/dotnet-buildtools/prereqs:ubuntu-22.04-debpkg

[MichaelSimons]

I likely had an incorrect notion. I thought that this repo was using CentOS Stream due to source build.

Also, why are we building this repo so many times? It would be good to see this choice covered.

Who is a good person to document the process and these design decisions?

I would start with @marcpopMSFT.

[nagilson]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[MiYanni]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[richlander]

We never resolved what to do here. Is the next step with @jkoritzinsky?

[marcpopMSFT]

The next step is to figure out what version runtime is building against and use that as we can't target a latest OS than they have in their 8.0 branch as otherwise we get the missing package error like here. @jkoritzinsky ?

[jkoritzinsky]

Runtime builds the runtime deps package with the centos.8 RID. Runtime doesn't float the RID based on the version it targets during the build. If you can adjust the build to not force match the RID for the validation testing, that should unblock this change.