Fix Windows MAX_PATH failure in Restore-RecordingsShared.ps1 (sparse-checkout + core.longpaths)

[m-nash]

Bug

eng/scripts/Restore-RecordingsShared.ps1 (introduced in #59341) fails on default Windows CI agents for any package whose recordings live at a long path in Azure/azure-sdk-assets. The build step Restore Recordings (shared clone) exits with error: unable to create file ... Filename too long and the test job aborts before any tests run. Linux/Mac aren't affected.

PR #59341 was validated against a 20-package set that didn't include any of the deep-path RM services, so the bug slipped through. Bigger test-batching matrix runs hit it: 11/50 Windows jobs failed on #58080, 24/100 on #57904.

Root cause

The script clones the assets repo per-package into <pkg>/.assets and runs git checkout refs/tags/<tag> -- .. The tag tree preserves the full repo layout (net/sdk/<svc>/<pkg>/...), and on a default Windows agent (LongPathsEnabled=0, no core.longpaths set) the resulting deep paths hit MAX_PATH (260). Test-proxy's own restore avoided this because it sparse-checks out only the package's subtree and sets core.longpaths itself.

Fix (Option 3 from the bug report - both arms)

1. core.longpaths=true - applied to the shared bare clone (idempotent, runs on both fresh and reused clones), and to each per-package clone (post-clone git config, plus -c core.longpaths=true on the per-invocation clone and checkout commands so even those individual operations have it active).
2. Sparse-checkout the package's own subtree per package: capture AssetsRepoPrefixPath from assets.json and DirectoryPath from package info, normalise to <prefix>/<dirpath> (forward slashes, slashes trimmed, empty segments dropped), then before checkout:
   • git -C <pkg>/.assets sparse-checkout init --cone
   • git -C <pkg>/.assets sparse-checkout set <prefix>/<dirpath>
     The final checkout drops the -- . pathspec so HEAD detaches cleanly to the tag with sparsity applied.

Sparse-checkout is the structurally correct change (matches test-proxy restore semantics, ~10x less data on disk per package). core.longpaths is the belt-and-suspenders defence that actually unblocks deep paths.

Verification

Local repro from the bug spec on a Windows box (with the fix):

• Azure.ResourceManager.ServiceFabricManagedClusters (canonical long-path package): succeeds. Deepest materialised path is 278 chars, the file ends up on disk.
• Azure.ResourceManager.NotificationHubs: succeeds.
• Re-runs against an existing shared clone: succeed (idempotent git config).
• Sparse-checkout confirmed: only net/sdk/<that-package>/... is materialised under .assets.

I could not reproduce the actual Filename too long error on my dev box because Windows LongPathsEnabled=1 is set in the registry there. Pre-fix I confirmed the materialised tree contains 30 files with paths > 260 chars (longest 317), which are exactly the files that fail the syscall on a default agent. The included README touch on Azure.ResourceManager.ServiceFabricManagedClusters is so CI exercises the deep-path restore on a real Windows agent and we can confirm the fix end-to-end.

Related

• Bug introduced by: Faster test-recording restore via shared clone #59341
• Reproduced on test PRs: test: 50 packages Weighted 10m/12m (DO NOT MERGE) #58080 (50 pkg), test: 100 packages Weighted 12m (DO NOT MERGE) #57904 (100 pkg)

[Copilot]

Pull request overview

Fixes Windows CI failures in Restore-RecordingsShared.ps1 caused by deep paths in Azure/azure-sdk-assets exceeding MAX_PATH on default Windows agents, by aligning the restore strategy with test-proxy restore.

Changes:

• Adds per-package sparse-checkout targeting <AssetsRepoPrefixPath>/<DirectoryPath> to avoid materializing the entire assets repo.
• Enables core.longpaths=true on both the shared bare clone and per-package clones (and for key git invocations) to support long paths on Windows.
• Touches Azure.ResourceManager.ServiceFabricManagedClusters README to ensure CI exercises the deep-path restore scenario on Windows.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
eng/scripts/Restore-RecordingsShared.ps1	Enables core.longpaths and adds sparse-checkout to restore only the relevant recordings subtree per package.
sdk/servicefabricmanagedclusters/Azure.ResourceManager.ServiceFabricManagedClusters/README.md	Adds a CI touch comment to ensure Windows CI validates the long-path restore fix.