Skip to content

build(wrapper): install only what the wrapper pipeline uses (main) - #3758

Open
Joywambui-maina wants to merge 4 commits into
mainfrom
fix/wrapper-pipeline-tools-main
Open

build(wrapper): install only what the wrapper pipeline uses (main)#3758
Joywambui-maina wants to merge 4 commits into
mainfrom
fix/wrapper-pipeline-tools-main

Conversation

@Joywambui-maina

Copy link
Copy Markdown
Contributor

Changes proposed in this pull request

  • Replace the install-tools.yml template in wrapper-release.yml with the three things this pipeline actually uses: the .NET 10 SDK (the WrapperGenerator targets net10.0; install-tools installs 8/6), NuGet feed authentication, and the kiota CLI (Build-WrapperModule.ps1 refuses to run without it on PATH, even under -SkipKiota).
  • Removes the inherited AutoRest toolchain from this pipeline's runs: Node, the private npm feed configuration, AutoRest, Rush and the full rush rebuild - none of which the wrapper build touches.

Same fix already applied to the powershell-v3 copy on #3753's branch; this syncs the copy merged to main via #3756. Answers the review question about rush/autorest: they came from reusing the v2 install template wholesale and are not needed for any wrapper check.

Other links

The pipeline reused install-tools.yml wholesale, which is the AutoRest
toolchain - Node, the private npm feed, AutoRest, Rush and a full rush
rebuild - none of which the wrapper build touches, and it installs .NET 8/6
while the generator targets net10.0. The build step then failed because
Build-WrapperModule.ps1 refuses to run without the kiota CLI on PATH even
under -SkipKiota. Installs the .NET 10 SDK, feed auth, and kiota explicitly.
…solation

api.nuget.org is not reliably reachable from the 1ES pool, so the kiota tool
install failed loading the service index - and the module restore would have
failed the same way one step later. Writes a pipeline-local nuget.config that
puts the MSGraph_PowerShell_V3_Build feed (whose upstream proxies nuget.org)
first with nuget.org as fallback, used by every restore on the run.
NuGetAuthenticate supplies the credentials; the kiota step also retries.
dotnet tool install probes the service index of every configured source and
fails hard if any is unreachable, so keeping nuget.org as a fallback defeated
the routing entirely. The pipeline config now lists only the internal feed,
whose upstream proxies nuget.org, and the install ignores failed sources.
Per review: the pipeline now generates the kiota client from the committed
OpenAPI docs and the wrappers on top, then compiles - the whole process is
built and tested end to end on every run, and a run can never fail on
committed clients lagging the docs. Clients remain committed to the repo for
reviewable diffs and clean local checkouts.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant