fix(cli): make temporary directory cleanup non-fatal in the Windows install script

Merged
AS
5d ago
+179-11

Summary

The generated scripts/install.ps1 deleted its download directory with Remove-Item -Recurse inside a finally block. On machines where $env:TEMP resolves to an 8.3 short path (a user profile such as C:\Users\USERNA~1.EXT), Windows PowerShell's filesystem provider fails that delete with An object at the specified path ... does not exist (see PowerShell/PowerShell#21070 and #7760). The exception propagated to the top-level handler and was reported as Installation failed even though the binary and PATH update had already succeeded.

Changes

  • Delete the temporary directory via [System.IO.Directory]::Delete($path, $true) instead of Remove-Item -Recurse. The .NET call does not go through the PowerShell filesystem provider, so it tolerates short-name path components.
  • Check for the directory with Test-Path -LiteralPath to match the delete call.
  • Wrap cleanup in its own try/catch and emit a warning naming the leftover folder, so a cleanup failure can no longer mask a completed install.

Testing

Regenerated the review CLI SDK; the only output change is scripts/install.ps1 and its gen.lock checksum. No PowerShell runtime is available locally, so the script was not executed.

Summary by cubic

Fixes the Windows install script so a failed temporary directory cleanup no longer reports a completed installation as failed.

  • The old cleanup used Remove-Item -Recurse, which fails when $env:TEMP resolves to an 8.3 short name like C:\Users\USERNA~1.EXT.
  • Uses Test-Path -LiteralPath and deletes via [System.IO.Directory]::Delete, which tolerates short paths, and wraps cleanup in a try/catch that prints a warning instead of throwing.
  • Adds a CI job that runs a new scripts/test-windows-installer.ps1 smoke test against the generated installer under both Windows PowerShell and PowerShell 7.
  • Updates the release snapshot tests-checklist checksum and adds a changeset entry; the script was not executed locally before the CI job was added.

Testing

  • The new CI job exercises the installer offline: it checks the installed binary, the download URL, and that a held-open temporary file produces a warning without failing the install.
  • On non-Windows hosts the held-file case is skipped because open files can be deleted there.