[CI] Add workaround for dotnet/runtime#91987 (NuGet-Migrations race condition) - #25797
Conversation
…ondition) Run 'dotnet --info' once right after downloading the .NET SDK to complete the first-time NuGet migrations logic. This avoids the race condition where multiple parallel dotnet processes attempt the first-time setup simultaneously, causing 'The system cannot open the device or file specified' errors. The workaround only runs in CI (when the ACES environment variable is set). Ref: dotnet/runtime#91987 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
There was a problem hiding this comment.
Pull request overview
This PR adds a CI-only workaround in the build system to avoid the NuGet first-time migrations race condition described in dotnet/runtime#91987 by forcing a single dotnet --info invocation immediately after the SDK download/installation step.
Changes:
- Run
dotnet --infoonce after installing the local SDK to complete first-time NuGet migrations. - Gate the workaround behind the
ACESenvironment variable to only run on CI/ACES agents.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
✅ [PR Build #3dbdd61] Build passed (Detect API changes) ✅Pipeline on Agent |
🔥 [CI Build #3dbdd61] Build failed (Detect API changes) 🔥Build failed for the job 'Detect API changes' (with job status 'Failed') Pipeline on Agent |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
✅ [CI Build #3dbdd61] Build passed (Build packages) ✅Pipeline on Agent |
✅ API diff for current PR / commitNET (empty diffs)✅ API diff vs stableNET (empty diffs)ℹ️ Generator diffGenerator Diff: vsdrops (html) vsdrops (raw diff) gist (raw diff) - Please review changes) Pipeline on Agent |
This comment has been minimized.
This comment has been minimized.
✅ [CI Build #3dbdd61] Build passed (Build macOS tests) ✅Pipeline on Agent |
❌ [CI Build #3dbdd61] Prepare .NET Release failed ❌The following jobs reported a non-successful result:
📦 Signed NuGet packages (32 packages)iOS
MacCatalyst
macOS
tvOS
Other
Pipeline on Agent |
This comment has been minimized.
This comment has been minimized.
🚀 [CI Build #3dbdd61] Test results 🚀Test results✅ All tests passed on VSTS: test results. 🎉 All 207 tests passed 🎉 Tests counts✅ assembly-processing: All 1 tests passed. Html Report (VSDrops) Download macOS tests✅ Tests on macOS Monterey (12): All 5 tests passed. Html Report (VSDrops) Download Linux Build VerificationPipeline on Agent |
…e condition) (#25797) Run 'dotnet --info' once right after downloading the .NET SDK to complete the first-time NuGet migrations logic. This avoids the race condition where multiple parallel dotnet processes attempt the first-time setup simultaneously, causing 'The system cannot open the device or file specified' errors. The workaround only runs in CI (when the ACES environment variable is set). Ref: dotnet/runtime#91987 --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Rolf Bjarne Kvinge <rokvin@microsoft.com> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
The previous workaround (from #25797) ran `dotnet --info` after downloading the SDK to trigger NuGet's first-time migration and avoid the race condition described in dotnet/runtime#91987. However, `dotnet --info` doesn't reliably trigger the migration code path -- the migration (`MigrationRunner.Run()`) is invoked from: 1. `DotnetFirstTimeUseConfigurer` in the dotnet CLI (first-use flow, which `--info` may bypass) 2. `NuGetSdkResolver` during MSBuild SDK resolution (only during build/restore) This PR replaces the `dotnet --info` call with directly creating the NuGet migration marker file (`~/.local/share/NuGet/Migrations/1`). When this file exists, NuGet's `MigrationRunner` returns immediately without acquiring the "NuGet-Migrations" mutex -- completely eliminating the race condition. The migration itself (`Migration1`) only cleans up old NuGet directories, which is a no-op on a fresh SDK installation, so skipping it is safe. Ref: dotnet/runtime#91987 Ref: https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.Common/Migrations/MigrationRunner.cs --- 🤖 Pull request created by Copilot --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…n workaround (#25849) (#25960) The previous workaround (from #25797) ran `dotnet --info` after downloading the SDK to trigger NuGet's first-time migration and avoid the race condition described in dotnet/runtime#91987. However, `dotnet --info` doesn't reliably trigger the migration code path -- the migration (`MigrationRunner.Run()`) is invoked from: 1. `DotnetFirstTimeUseConfigurer` in the dotnet CLI (first-use flow, which `--info` may bypass) 2. `NuGetSdkResolver` during MSBuild SDK resolution (only during build/restore) This PR replaces the `dotnet --info` call with directly creating the NuGet migration marker file (`~/.local/share/NuGet/Migrations/1`). When this file exists, NuGet's `MigrationRunner` returns immediately without acquiring the "NuGet-Migrations" mutex -- completely eliminating the race condition. The migration itself (`Migration1`) only cleans up old NuGet directories, which is a no-op on a fresh SDK installation, so skipping it is safe. Ref: dotnet/runtime#91987 Ref: https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.Common/Migrations/MigrationRunner.cs --- 🤖 Pull request created by Copilot --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…und (#25996) The previous workaround (from #25797) ran `dotnet --info` after downloading the SDK to trigger NuGet's first-time migration and avoid the race condition described in dotnet/runtime#91987. However, `dotnet --info` doesn't reliably trigger the migration code path -- the migration (`MigrationRunner.Run()`) is invoked from: 1. `DotnetFirstTimeUseConfigurer` in the dotnet CLI (first-use flow, which `--info` may bypass) 2. `NuGetSdkResolver` during MSBuild SDK resolution (only during build/restore) This PR replaces the `dotnet --info` call with directly creating the NuGet migration marker file (`~/.local/share/NuGet/Migrations/1`). When this file exists, NuGet's `MigrationRunner` returns immediately without acquiring the "NuGet-Migrations" mutex -- completely eliminating the race condition. The migration itself (`Migration1`) only cleans up old NuGet directories, which is a no-op on a fresh SDK installation, so skipping it is safe. Ref: dotnet/runtime#91987 Ref: https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.Common/Migrations/MigrationRunner.cs --- 🤖 Pull request created by Copilot --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Backport of #25960. Backport of #25849. --------- Co-authored-by: Rolf Bjarne Kvinge <rokvin@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Run 'dotnet --info' once right after downloading the .NET SDK to complete the first-time NuGet migrations logic. This avoids the race condition where multiple parallel dotnet processes attempt the first-time setup simultaneously, causing 'The system cannot open the device or file specified' errors.
The workaround only runs in CI (when the ACES environment variable is set).
Ref: dotnet/runtime#91987