dotnet
Update CentOS version -- release/8.0.1xx
@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?
Good point. I don't know the specifics. Can you log a tracking bug in runtime @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.
@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.
https://github.com/dotnet/source-build/issues/4890
Yes.
Min CentOS Stream versions by .NET version / branch:
- .NET 8/9: Stream 9
- .NET 10: Stream 10
https://github.com/dotnet/sdk/issues/46721
@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.
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.
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?
https://github.com/dotnet/installer/blob/4b46c441dccb7717d47521c67da3681431e4c222/.vsts-ci.yml#L46-L65
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.
![azure-pipelines[bot] avatar](https://avatars.githubusercontent.com/in/9426?v=4 "Published by a pub.dev verified publisher"){kind=small}
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 ?
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.
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.
Coming back to this, I just hardcoded the rid update back to the centos8 one as this is in servicing and not something we'll be carrying forward (so a quick hack seemed better than some more comprehensive solution which we've already put into net10). If this passes, we should review the other versions we are building against to get them on an updated version if we can.
@jkoritzinsky I didn't notice your change but it wasn't enough to fix this. Let's see if mine does and we can revert yours potentially as part of updating the other legs that are also out of date.
it built this time but tests failed. Will have to investigate more next week: _error NETSDK1083: The specified RuntimeIdentifier 'centos.8-x64' is not recognized. See https://aka.ms/netsdk1083 for more information. [/_w/1/s/artifacts/bin/EndToEnd.Tests/Debug/net8.0/Tests/EndToEnd.Tests/InstantiateProjectTemplateconsole[VB]/InstantiateProjectTemplateconsole[VB].vbproj]
I can confirm that the test isn't setting the RID. Not sure why we're getting a centos8 default rid then.
[31;1m Microsoft.NET.Build.Tests.GivenThatWeWantToBuildANetCoreApp.It_runs_a_rid_specific_app_with_conflicts_from_the_output_folder(targetFramework: "netcoreapp2.0") [FAIL] _[m[37m Failed to load H? ma, error: libunwind.so.8: cannot open shared object file: No such file or directory [m[37m Failed to bind to CoreCLR at '/_w/1/s/artifacts/tmp/Debug/dotnetSdkTests/.nuget/packages/runtime.linux-x64.microsoft.netcore.app/2.0.9/runtimes/linux-x64/native/libcoreclr.so'
Suppressing this test on linux as it's failing on the 2.0 version when run on centos9.