[DRAFT - CI validation only] Fix WixToolset.Sdk resolution under CFSClean feed pinning - #1948
Closed
v-sohmondal wants to merge 7 commits into
Closed
v-sohmondal wants to merge 7 commits into
v-sohmondal wants to merge 7 commits into
Conversation
MSBuild resolves MSI.wixproj's WixToolset.Sdk at evaluation time through the NuGet SDK resolver, which does not use the Azure Artifacts credential provider and ignores nugetConfigPath (NuGet/Home#7855, NuGet/Home#10178). Once restores were pinned to the private feed in src/nuget.config it could authenticate to neither that feed nor nuget.org (blocked by CFSClean), so every job failed with MSB4236 "The SDK WixToolset.Sdk/4.0.1 specified could not be found". Add build/prepare-nuget.yml, a shared step template that authenticates and then downloads the SDK into the NuGet global packages folder before anything evaluates the solution, so SDK resolution succeeds offline. The version is read from MSI.wixproj so the two cannot drift. The template also replaces the NuGetAuthenticate steps that were duplicated across six call sites. Also: - check-dependencies.yml: move networkIsolationPolicy from pool: to templateContext.settings - signedbuild.yml: un-nest feedsToUse/nugetConfigPath from the projects: block scalar in all three DotNetCoreCLI@2 restores, where they were being treated as project globs rather than task inputs Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 0add1f23-4df3-4efa-8237-fe45d7d5e747
Contributor
Author
|
/azp run |
The Accessibility Insights build service was missing ReadPackages on the a11y-insights-public feed, which surfaced as a 403 and, in the SDK resolver, as "Unable to load the service index" - the same symptom the seed step was built to work around. Now that the permission is granted, remove the seed to determine whether the NuGet SDK resolver can authenticate on its own. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 0add1f23-4df3-4efa-8237-fe45d7d5e747
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
Contributor
Author
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
Contributor
Author
|
Validation complete: the failure was a missing ReadPackages grant for the Accessibility Insights build service on the a11y-insights-public feed, not an SDK resolver limitation - with the permission granted, build 63775 on #1947 restores cleanly and reports CFSClean COMPLIANT with no seeding workaround, so closing this throwaway branch. |
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
2 participants
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.
Purpose
#1947 pins all restores to the private Azure Artifacts feed for SFI-ES4.2.4 (CFSClean). Every job in it currently fails:
Root cause
src/MSI/MSI.wixprojimportsWixToolset.Sdkas an MSBuild project SDK. MSBuild resolves project SDKs at evaluation time via the NuGet SDK resolver, which is a different code path from package restore: it does not use the Azure Artifacts credential provider and ignoresnugetConfigPath(NuGet/Home#7855, NuGet/Home#10178).So it can reach neither the private feed (401) nor nuget.org (blocked by CFSClean). It is the only NuGet-delivered MSBuild SDK in the repo — the other 29 projects use the in-box
Microsoft.NET.Sdk*, which resolve from disk.Notably this is not a permissions issue:
Project Collection Build Servicealready has Collaborator on the feed,NuGetAuthenticate@1succeeds, andWixToolset.Sdk 4.0.1is cached there.Change
build/prepare-nuget.yml— a shared step template that authenticates, then downloads the SDK into the NuGet global packages folder before anything evaluates the solution, so resolution succeeds offline. The version is read fromMSI.wixprojso the two cannot drift. It also replaces theNuGetAuthenticate@1step duplicated across six call sites.Plus two correctness fixes:
check-dependencies.yml—networkIsolationPolicymoved frompool:totemplateContext.settingssignedbuild.yml—feedsToUse/nugetConfigPathun-nested from theprojects: |block scalar in all threeDotNetCoreCLI@2restores, where they were being parsed as project globsVerified locally
MSI.wixprojresolves its SDK against a completely unreachable feedMSB4236failureWhat this PR is meant to prove
- template: prepare-nuget.yml) works in ADOStop Network Isolationreports CFSClean COMPLIANT