The build ID that I initially set is getting overridden in the repo-builds:

./build.sh --ci --clean-while-building --prepareMachine -c Release --online --source-only /p:VerticalName=CentOSStream9_Online_MsftSdk_x64 /p:ArtifactsStagingDir=/__w/1/a -arch x64 /p:OfficialBuildId=20991231.99
...
src/source-build-reference-packages/eng/common/build.sh --restore --build --pack --publish --ci --configuration Release --verbosity minimal /p:TargetRid=centos.9-x64 /p:OfficialBuildId=20250508.1

8 scenario tests are failing - I'm investigating

Oh, sure. This would be expected. We're in a funky configuration here because we're setting the official build ID but we also don't have access to all the Microsoft build artifacts that we would normally have in an official build. This will all get sorted out with my pipeline changes. I have changes that only include these failing tests to be run when it's an official build as we can't run them in PR builds. You could add temporary changes that would skip these tests for a PR build but that would just be temporary and get removed by my changes. @MichaelSimons - Thoughts on just disabling these failing tests entirely for now?

Thoughts on just disabling these failing tests entirely for now?

That sounds like a reasonable plan to unblock.

Thoughts on just disabling these failing tests entirely for now?

That sounds like a reasonable plan to unblock.

Disabled the failing tests in 6f63092

There are some more tests that need to be disabled.

@ellahathaway @ViktorHofer @mthalman @MichaelSimons Do you think this is the right place to also do an update of the arcade global.json to the matching 10.0.100-preview.5.25230.108 SDK? My gut is saying yes.

Alright stage 1 is passing now! But stage 2 is failing to build the tests.

scenario-tests fails to build with this error:

/__w/1/s/.packages/tests/BootstrapPackages/microsoft.dotnet.arcade.sdk/10.0.0-beta.99631.199/tools/Tools.proj : error NU1102: Unable to find package Microsoft.DotNet.Build.Tasks.Feed with version (>= 10.0.0-beta.99631.199)
/__w/1/s/.packages/tests/BootstrapPackages/microsoft.dotnet.arcade.sdk/10.0.0-beta.99631.199/tools/Tools.proj : error NU1102:   - Found 1159 version(s) in dotnet-eng [ Nearest version: 10.0.0-beta.25263.104 ]
/__w/1/s/.packages/tests/BootstrapPackages/microsoft.dotnet.arcade.sdk/10.0.0-beta.99631.199/tools/Tools.proj : error NU1102:   - Found 0 version(s) in dotnet-libraries
/__w/1/s/.packages/tests/BootstrapPackages/microsoft.dotnet.arcade.sdk/10.0.0-beta.99631.199/tools/Tools.proj : error NU1102:   - Found 0 version(s) in dotnet-public

I ran into this same issue with #400. I'll add the fix here.

@ellahathaway @ViktorHofer @mthalman @MichaelSimons Do you think this is the right place to also do an update of the arcade global.json to the matching 10.0.100-preview.5.25230.108 SDK? My gut is saying yes.

I think we should be updating it along with the VMR's eng/common as part of bootstrapping. I lean towards that we should get this in w/o additional changes to unblock folks and then circle around with another rebootstrap w/these additional changes.

Some legs are failing with the following NU1901 errors:

- error NU1901: (NETCORE_ENGINEERING_TELEMETRY=Restore) Package 'Microsoft.Build.Tasks.Core' 17.8.3 has a known low severity vulnerability
- error NU1901: (NETCORE_ENGINEERING_TELEMETRY=Restore) Package 'Microsoft.Build.Tasks.Core' 17.12.6 has a known low severity vulnerability

In one leg, the error did not occur on a retry of the build. What's odd is that NU1901 is included as a warning not to error on.

Also, the errors seem inconsistent, as some legs did not fail at the same place on retry.

Some legs are failing with the following NU1901 errors:

This is a known issue - see #546

Some legs are failing with the following NU1901 errors:

This is a known issue - see #546

Thoughts on merging this on red then? The SB legs are passing, and the UB legs were passing before the nuget audit warnings hit.

The SB leg is still failing, isn't it?

The SB leg is still failing, isn't it?

This is the old SB PR validation leg. It is being replaced in this PR by the UB SB PR leg. Once merged I will removed the old dotnet-source-build as a required check.

The SB legs are passing, and the UB legs were passing before the nuget audit warnings hit.

Well, stage 1 was passing. We never got a chance to see if my fix got stage 2 to pass.

The SB legs are passing, and the UB legs were passing before the nuget audit warnings hit.

Well, stage 1 was passing. We never got a chance to see if my fix got stage 2 to pass.

Your fix was included in https://dev.azure.com/dnceng-public/public/_build/results?buildId=1041355&view=results, which shows that stage 2 was passing.