build: scope the perfview-build feed to the package it provides - #5528
Draft
jamescrosswell wants to merge 1 commit into
Draft
build: scope the perfview-build feed to the package it provides#5528jamescrosswell wants to merge 1 commit into
jamescrosswell wants to merge 1 commit into
Conversation
nuget.config maps perfview-build to the "*" package pattern, so NuGet queries that single-purpose feed for every package in the repo. It proxies upstream and answers 401 - not 404 - for any package version it has not already cached, and NuGet treats a 401 from any mapped source as fatal. Every new package version in the repo therefore depends on that proxy succeeding. That was harmless for years while the feed served everything, and started failing today when its anonymous upstream fetches began returning 401. It takes out restore on main: Workload update failed: 401 (Unauthorized - No local versions of package 'microsoft.net.workloads.10.0.400.msi.x64'; please provide authentication to access versions from upstream that have not yet been saved to your feed.) The feed is still needed, for exactly one package: the perfview submodule wants Microsoft.Diagnostics.Tracing.TraceEvent.SupportFiles 1.0.30, and nuget.org only publishes up to 1.0.23. Scoping the mapping to that package keeps it resolvable while removing the repo's dependency on the feed for anything else. The other eleven packages the perfview projects reference are all on nuget.org at their required versions. Verified with a cold restore of Sentry-CI-Build-macOS.slnf into an empty packages folder: 6.1 GB fetched, no errors, SupportFiles 1.0.30 resolved from perfview-build. #skip-changelog
jamescrosswell
force-pushed
the
build/nuget-perfview-source-mapping
branch
from
September 1, 2026 06:55
9e76ef8 to
f93800f
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #5528 +/- ##
==========================================
+ Coverage 74.66% 74.77% +0.11%
==========================================
Files 515 515
Lines 18909 18909
Branches 3691 3691
==========================================
+ Hits 14118 14140 +22
+ Misses 3906 3881 -25
- Partials 885 888 +3 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
nuget.configmaps theperfview-buildfeed to the*package pattern, so NuGet queries that single-purpose feed for every package in the repo. It proxies upstream and answers 401 — not 404 — for any package version it has not already cached, and NuGet treats a 401 from any mapped source as fatal.That was harmless for years while the feed served everything, and started failing today when its anonymous upstream fetches began returning 401. It takes out restore on
main:This is an external outage, not a code change —
mainwas green as recently as the run for #5503 (2026-08-31T11:14), and the only change before the first red run (2026-09-01T01:21) was #5513, a workflow file. The feed still 401s on those packages as of writing.Why the feed is still needed
For exactly one package. The
perfviewsubmodule referencesMicrosoft.Diagnostics.Tracing.TraceEvent.SupportFiles, and nuget.org only publishes up to 1.0.23:So this predates the recent submodule bump — the bump moved 1.0.29 → 1.0.30, both of which are perfview-build-only.
The other eleven packages the perfview projects reference (
MicroBuild.Core,Microsoft.Bcl.HashCode,Microsoft.Diagnostics.NETCore.Client,Microsoft.Win32.Registry,System.Collections.Immutable,System.IO.Hashing,System.Reflection.Metadata,System.Reflection.TypeExtensions,System.Runtime.CompilerServices.Unsafe,System.Text.Json,Microsoft.SourceLink.GitHub) are all on nuget.org at their exact required versions.Scoping the mapping to that one package keeps it resolvable while removing the repo's dependency on the feed for everything else, so a future dnceng hiccup can't take out CI again.
Verification
Cold restore of
Sentry-CI-Build-macOS.slnfinto an empty packages folder (not the warm local cache): 6.1 GB fetched, no errors, andSupportFiles 1.0.30confirmed resolved fromperfview-build.dotnet-publicis healthy and stays mapped to*.#skip-changelog