[build] Fix NuGet migration race condition workaround#25833
Conversation
The previous workaround ran 'dotnet --info' to trigger the first-time NuGet migration, but this command doesn't reliably trigger the migration code path. The migration is triggered by DotnetFirstTimeUseConfigurer (first CLI use) and NuGetSdkResolver (MSBuild SDK resolution), neither of which is invoked by 'dotnet --info'. Instead, directly create the NuGet migration marker file (~/.local/share/NuGet/Migrations/1). When this file exists, NuGet's MigrationRunner.Run() skips the mutex entirely, eliminating the race condition. The migration itself (Migration1) only cleans up old NuGet directories, which is a no-op on a fresh SDK installation. Ref: dotnet/runtime#91987 Ref: https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.Common/Migrations/MigrationRunner.cs Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
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 #959ede6] Build passed (Detect API changes) ✅Pipeline on Agent |
✅ [PR Build #959ede6] Build passed (Build packages) ✅Pipeline on Agent |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
✅ 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 |
✅ [CI Build #959ede6] Build passed (Build macOS tests) ✅Pipeline on Agent |
🔥 [CI Build #959ede6] Test results 🔥Test results❌ Tests failed on VSTS: test results 5 tests crashed, 0 tests failed, 174 tests passed. Failures❌ Tests on macOS Monterey (12) tests🔥 Failed catastrophically on VSTS: test results - mac_monterey (no summary found). Html Report (VSDrops) Download ❌ Tests on macOS Ventura (13) tests🔥 Failed catastrophically on VSTS: test results - mac_ventura (no summary found). Html Report (VSDrops) Download ❌ Tests on macOS Sonoma (14) tests🔥 Failed catastrophically on VSTS: test results - mac_sonoma (no summary found). Html Report (VSDrops) Download ❌ Tests on macOS Sequoia (15) tests🔥 Failed catastrophically on VSTS: test results - mac_sequoia (no summary found). Html Report (VSDrops) Download ❌ Tests on macOS Tahoe (26) tests🔥 Failed catastrophically on VSTS: test results - mac_tahoe (no summary found). Html Report (VSDrops) Download Successes✅ assembly-processing: All 1 tests passed. Html Report (VSDrops) Download macOS testsLinux Build VerificationPipeline on Agent |
2 participants
The previous workaround (from #25797) ran
dotnet --infoafter downloading the SDK to trigger NuGet's first-time migration and avoid the race condition described in dotnet/runtime#91987. However,dotnet --infodoesn't reliably trigger the migration code path -- the migration (MigrationRunner.Run()) is invoked from:DotnetFirstTimeUseConfigurerin the dotnet CLI (first-use flow, which--infomay bypass)NuGetSdkResolverduring MSBuild SDK resolution (only during build/restore)This PR replaces the
dotnet --infocall with directly creating the NuGet migration marker file (~/.local/share/NuGet/Migrations/1). When this file exists, NuGet'sMigrationRunnerreturns 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