Repository navigation
Document the internal NuGet feed needed to run tests on a corp machine - #746
Merged
Nikola Metulev (nmetulev) merged 2 commits intoAug 13, 2026
Merged
Conversation
api.nuget.org is unreachable from Microsoft corporate machines, so every test that downloads Microsoft.Windows.SDK.BuildTools fails with an SSL error. The failure looks exactly like a transient network fault, and nothing in AGENTS.md said otherwise -- so the natural reading is "flaky, re-run it", which is wrong and wastes a lot of time. NugetService already supports the internal feed via WINAPP_NUGET_*, and CI sets those in .pipelines/templates/build.yaml. That was just never written down for anyone working locally. Adds the values, the token step, a probe to check the feed answers before committing to a long run, and the general rule this is an instance of: if it fails locally but passes in CI, the difference is configuration, not luck.
Copilot started reviewing on behalf of
Alexandre Zollinger Chohfi (azchohfi)
August 13, 2026 17:52
View session
Contributor
There was a problem hiding this comment.
Pull request overview
Documents the internal NuGet feed configuration required to run package-dependent tests on Microsoft corporate machines.
Changes:
- Adds feed environment variables, authentication setup, and connectivity probe.
- Clarifies that NuGet failures require matching CI configuration rather than retries.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Alexandre Zollinger Chohfi (azchohfi)
requested a balanced review from Copilot
August 13, 2026 18:01
Copilot started reviewing on behalf of
Alexandre Zollinger Chohfi (azchohfi)
August 13, 2026 18:01
View session
Nikola Metulev (nmetulev)
deleted the
azchohfi-document-internal-nuget-feed
branch
August 13, 2026 18:16
This was referenced Sep 24, 2026
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.
Problem
api.nuget.orgis unreachable from Microsoft corporate machines, so any test that downloadsMicrosoft.Windows.SDK.BuildTools— most of thePackageCommand,SignCommandandMsixServicecoverage — fails with:That is indistinguishable from a transient network fault, and nothing in
AGENTS.mdsaid otherwise. The natural conclusion is "flaky, re-run it" or "environmental, let CI decide" — both wrong, and both waste real time. I hit this exact trap on #745: I saw the SSL error, probedapi.nuget.orgto confirm it was unreachable, and reported the failures as environmental. The probe confirmed my hypothesis instead of testing it, and I never asked the question that would have settled it in one grep — how does CI run these same tests successfully?Change
Documentation only. A new section under Developer workflows covering:
WINAPP_NUGET_*values, matching what.pipelines/templates/build.yamlalready sets in CI.VSS_NUGET_ACCESSTOKENstep, and the detail that auth is BasicVssSessionToken:<token>applied only to URLs under the auth prefix.The capability already existed —
NugetServicefalls back toapi.nuget.orgonly when these are unset. It was simply never written down for anyone working outside CI.Verification
Followed the documented steps from a clean shell, then re-ran the two tests that had failed:
The probe command is also verified — it returns 379 versions of
Microsoft.Windows.SDK.BuildTools.Note
AGENTS.mdis the only instruction file in the repo (noCONTRIBUTING.md,copilot-instructions.mdorCLAUDE.md), so this is the single place it needs to live.