Sync downstream CI with upstream daily CI versions

[tmds]

For our daily CI use-cases we have depencies on packages that we do not source-build.

For example, we get the following error when trying to build aspnetcore with an internal CI SDK due to a mismatch for Microsoft.NETCore.App.Runtime.Mono.browser-wasm:

HostedBlazorWebassemblyApp.Client.csproj : error NU1102: Unable to find package Microsoft.NETCore.App.Runtime.Mono.browser-wasm with version (= 10.0.0-preview.6.25310.101) [/tmp/tmp.PBEgsEvJDL/sdk/10.0.100-preview.6.25310.101/NuGet.targets]
HostedBlazorWebassemblyApp.Client.csproj : error NU1102:   - Found 1458 version(s) in dotnet8 [ Nearest version: 8.0.0-rtm.23523.3 ] [/tmp/tmp.PBEgsEvJDL/sdk/10.0.100-preview.6.25310.101/NuGet.targets]
HostedBlazorWebassemblyApp.Client.csproj : error NU1102:   - Found 1417 version(s) in dotnet9 [ Nearest version: 9.0.0-rtm.24516.5 ] [/tmp/tmp.PBEgsEvJDL/sdk/10.0.100-preview.6.25310.101/NuGet.targets]
HostedBlazorWebassemblyApp.Client.csproj : error NU1102:   - Found 1224 version(s) in dotnet10 [ Nearest version: 10.0.0-preview.6.25310.107 ] [/tmp/tmp.PBEgsEvJDL/sdk/10.0.100-preview.6.25310.101/NuGet.targets]
HostedBlazorWebassemblyApp.Client.csproj : error NU1102:   - Found 119 version(s) in dotnet-public [ Nearest version: 10.0.0-preview.5.25277.114 ] [/tmp/tmp.PBEgsEvJDL/sdk/10.0.100-preview.6.25310.101/NuGet.targets]
HostedBlazorWebassemblyApp.Client.csproj : error NU1102:   - Found 0 version(s) in source L2hvbWUvdGVzdGVyL3dvcmtkaXIvZ3JwYy9hcnRpZmFjdHMK [/tmp/tmp.PBEgsEvJDL/sdk/10.0.100-preview.6.25310.101/NuGet.targets]
HostedBlazorWebassemblyApp.Client.csproj : error NU1102:   - Found 0 version(s) in dotnet-eng [/tmp/tmp.PBEgsEvJDL/sdk/10.0.100-preview.6.25310.101/NuGet.targets]
HostedBlazorWebassemblyApp.Client.csproj : error NU1102:   - Found 0 version(s) in dotnet-tools [/tmp/tmp.PBEgsEvJDL/sdk/10.0.100-preview.6.25310.101/NuGet.targets]
HostedBlazorWebassemblyApp.Client.csproj : error NU1102:   - Found 0 version(s) in dotnet10-transport [/tmp/tmp.PBEgsEvJDL/sdk/10.0.100-preview.6.25310.101/NuGet.targets]
HostedBlazorWebassemblyApp.Client.csproj : error NU1102:   - Found 0 version(s) in dotnet8-transport [/tmp/tmp.PBEgsEvJDL/sdk/10.0.100-preview.6.25310.101/NuGet.targets]
HostedBlazorWebassemblyApp.Client.csproj : error NU1102:   - Found 0 version(s) in dotnet9-transport [/tmp/tmp.PBEgsEvJDL/sdk/10.0.100-preview.6.25310.101/NuGet.targets]

I'd like to explore syncing our downstream daily builds with the upstream official daily build versions.

What would be a way to find the most recent OfficialBuildId from the official daily builds?
And the vmr commit that it was built from?

cc @ViktorHofer @mmitche @MichaelSimons @omajid

[omajid]

Maybe we can use productCommit-$rid.json ?

curl -sSL https://aka.ms/dotnet/10.0.1xx/daily/productCommit-linux-x64.json
{
  "runtime": { "commit": "8962a64a421ddfa026482f404f45352ebaea7891", "version": "10.0.0-preview.6.25316.101" },
  "aspnetcore": { "commit": "8962a64a421ddfa026482f404f45352ebaea7891", "version": "10.0.0-preview.6.25316.101" },
  "windowsdesktop": { "commit": "8962a64a421ddfa026482f404f45352ebaea7891", "version": "10.0.0-preview.6.25311.102" },
  "sdk": { "commit": "8962a64a421ddfa026482f404f45352ebaea7891", "version": "10.0.100-preview.6.25316.101" }
}

The VMR commit is listed as the commit field (duplicated for all repos), and the OfficiailBuildId is available from the version string.

See also dotnet/dotnet#1056

[tmds]

https://aka.ms/dotnet/10.0.1xx/daily/productCommit-linux-x64.json

Interesting.

and the OfficiailBuildId is available from the version string.

I was hoping not to have to reverse engineer it.

[tmds]

I wonder if Microsoft.NETCore.App.Runtime.Mono.browser-wasm nuget package and linux-x64 SDK will have a same daily version.

Does something orchestrate official daily builds use the same commit and OfficialBuildId?

[tmds]

I'm implementing this using https://aka.ms/dotnet/10.0.1xx/daily/productCommit-linux-x64.json.

If there is another source that has the OfficialBuildId directly, it would be handy.

I'm also interested to know if all the Microsoft daily builds try to build the same OfficialBuildId?
Today's https://github.com/dotnet/dotnet/blob/main/docs/builds-table.md has the same version for all builds.

[MichaelSimons]

This issue should be resolved with dotnet/dotnet#1053.

[tmds]

This issue should be resolved with dotnet/dotnet#1053.

I don't understand how. We can see when it is implemented if it does or how it helps.

The main question here is how to sync with the upstream daily CI in order to be able to use artifacts from Microsoft NuGet CI feeds that our downstream daily CI doesn't build.

[MichaelSimons]

Unable to find package Microsoft.NETCore.App.Runtime.Mono.browser-wasm with version (= 10.0.0-preview.6.25310.101)

My understanding is stable versioning will address this because the package version will become 10.0.0-preview.6 and allow alignment between SB and MSFT builds. This could however become problematic if there are API differences.

@mmitche can you provide you perspective here?

[mmitche]

@MichaelSimons @tmds is talking about rolling CI, rather than preview/rc releases. For those, we are still planning to maintain the non-stable versioning. I think would be pretty dicey to have the VMR always build stable. It would work, but greatly increases the possibility of issues when devs are dogfooding locally.

I'm also interested to know if all the Microsoft daily builds try to build the same OfficialBuildId?
Today's https://github.com/dotnet/dotnet/blob/main/docs/builds-table.md has the same version for all builds.

That table means that everything was produced from the same build. If a different build produced a different set of artifacts (e.g. say it was aspire), the numbers wouldn't be aligned.

I agree that @tmds shouldn't have to reverse-engineer OfficialBuildId from the output package versions. The info is contained within the MergedManifest, which is great. However, that's not stable linked (and non-trivial to do so in the current artifact layout).

Maybe add another field to productCommit-$rid.json file?

curl -sSL https://aka.ms/dotnet/10.0.1xx/daily/productCommit-linux-x64.json
{
  "runtime": { "commit": "8962a64a421ddfa026482f404f45352ebaea7891", "version": "10.0.0-preview.6.25316.101", "officialBuildId": "20250619.1"  },
  "aspnetcore": { "commit": "8962a64a421ddfa026482f404f45352ebaea7891", "version": "10.0.0-preview.6.25316.101", "officialBuildId": "20250619.1" },
  "windowsdesktop": { "commit": "8962a64a421ddfa026482f404f45352ebaea7891", "version": "10.0.0-preview.6.25311.102", "officialBuildId": "20250619.1" },
  "sdk": { "commit": "8962a64a421ddfa026482f404f45352ebaea7891", "version": "10.0.100-preview.6.25316.101", "officialBuildId": "20250619.1" }
}