shadow-testandClaude Opus 5
29fd7de909
Build App / compute-version (pull_request) Successful in 6s
Build Container / build-container (pull_request) Successful in 1m40s
Build App / build-macos (pull_request) Successful in 2m32s
Build App / build-windows (pull_request) Successful in 5m13s
Build App / build-linux (pull_request) Successful in 6m29s
Build App / create-tag (pull_request) Skipped
Build App / sync-to-github (pull_request) Skipped
Dropping the MSI did not help, because the problem was never WiX. makensis.exe is 32-bit exactly like candle.exe and light.exe, lives in the same SYSTEM-profile cache, and failed the same way — "Unable to start child process, error 0x2" instead of 0x80131700. The cause is WOW64 redirection: a 32-bit process reading C:\Windows\System32 is served C:\Windows\SysWOW64, where the toolset directory does not exist, so the bundlers cannot see their own folder. The build VM now carries two junctions from the SysWOW64 view of systemprofile\AppData\Local\tauri and systemprofile\.cache to the System32 originals. Verified afterwards on the runner: candle.exe reports "WiX Toolset Compiler version 3.14.1.8722" and exits 0, and makensis reports v3.11 and exits 0 — both from the same path that failed before. So both targets build again and the .msi asset comes back. Artifact collection fails if either installer is missing rather than tolerating an empty directory. This is a host-side patch for a runner running as SYSTEM. A runner running as a normal user has a LOCALAPPDATA outside System32 and needs none of it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>