Summary
The Windows Installer (Pester) CI job (test/windows/install.Tests.ps1) started failing on the v0.8.9 release commit (8fea4337d2), even though that commit only changed CHANGELOG.md and renamed a test file — install.ps1 and its tests were untouched. The identical code passed on the two prior pushes (#930 on 2026-06-16, #946 on 2026-06-18). A re-run of the failed job reproduced the failure deterministically.
This is a flaky test-harness bug on the updated windows-latest runner image, not a product regression. The v0.8.9 release itself (npm publish, GitHub release, all platform binaries including win32-x64) is green, and install.ps1 behaves correctly for real users.
Failing tests (3 of 9)
rejects genuine 32-bit x86 (no ARCHITEW6432)rejects ARM64rejects an unknown pinned version with a friendly error
All three override PROCESSOR_ARCHITECTURE, and the child process saw it blank — output was error: Unsupported OS/Arch: windows/ with no arch after the slash.
Root cause
Invoke-Installer set env vars via [Environment]::SetEnvironmentVariable (Process scope) on the Pester host, then spawned & pwsh -File, relying on inheritance. PROCESSOR_ARCHITECTURE is a loader-managed variable; the updated windows-latest runner re-initializes it for spawned processes, so the override no longer reaches the child (it arrives blank). Custom vars like PROCESSOR_ARCHITEW6432 are unaffected — which is why the WOW64 test still passes.
Fix
Apply the requested env vars inside the child's own session via a pwsh -Command preamble (after the loader runs) instead of relying on inherited Process-scope overrides. Empty values Remove-Item the var so "missing PROCESSOR_ARCHITEW6432" detection still works. All existing test expectations are preserved.
Summary
The
Windows Installer (Pester)CI job (test/windows/install.Tests.ps1) started failing on thev0.8.9release commit (8fea4337d2), even though that commit only changedCHANGELOG.mdand renamed a test file —install.ps1and its tests were untouched. The identical code passed on the two prior pushes (#930 on 2026-06-16, #946 on 2026-06-18). A re-run of the failed job reproduced the failure deterministically.This is a flaky test-harness bug on the updated
windows-latestrunner image, not a product regression. The v0.8.9 release itself (npm publish, GitHub release, all platform binaries includingwin32-x64) is green, andinstall.ps1behaves correctly for real users.Failing tests (3 of 9)
rejects genuine 32-bit x86 (no ARCHITEW6432)rejects ARM64rejects an unknown pinned version with a friendly errorAll three override
PROCESSOR_ARCHITECTURE, and the child process saw it blank — output waserror: Unsupported OS/Arch: windows/with no arch after the slash.Root cause
Invoke-Installerset env vars via[Environment]::SetEnvironmentVariable(Process scope) on the Pester host, then spawned& pwsh -File, relying on inheritance.PROCESSOR_ARCHITECTUREis a loader-managed variable; the updatedwindows-latestrunner re-initializes it for spawned processes, so the override no longer reaches the child (it arrives blank). Custom vars likePROCESSOR_ARCHITEW6432are unaffected — which is why the WOW64 test still passes.Fix
Apply the requested env vars inside the child's own session via a
pwsh -Commandpreamble (after the loader runs) instead of relying on inherited Process-scope overrides. Empty valuesRemove-Itemthe var so "missingPROCESSOR_ARCHITEW6432" detection still works. All existing test expectations are preserved.