From 29fd7de909864fecd82eec5e2ec24b25baaf7136 Mon Sep 17 00:00:00 2001 From: Josh Knapp Date: Sun, 9 Aug 2026 22:34:43 -0700 Subject: [PATCH] CI: restore the MSI now that the 32-bit bundlers can resolve their paths MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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) --- .gitea/workflows/build-app.yml | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/.gitea/workflows/build-app.yml b/.gitea/workflows/build-app.yml index b560c9e..aa05136 100644 --- a/.gitea/workflows/build-app.yml +++ b/.gitea/workflows/build-app.yml @@ -454,23 +454,25 @@ jobs: TAURI_CONFIG: "{\"build\":{\"beforeBuildCommand\":\"\"}}" run: | set "PATH=%USERPROFILE%\.cargo\bin;C:\Program Files\nodejs;%PATH%" - rem NSIS only: the MSI target needs WiX, whose candle.exe/light.exe are - rem 32-bit. On a runner running as SYSTEM, Tauri caches WiX under - rem %LOCALAPPDATA% = C:\Windows\system32\config\systemprofile\..., and - rem WOW64 redirection points 32-bit processes at SysWOW64, where that - rem directory does not exist - so candle cannot see its own folder and - rem dies with 0x80131700. Tauri aborts the whole bundle when one target - rem fails, so the MSI was also costing us the NSIS installer. + rem Every Tauri bundler it downloads - candle.exe, light.exe and + rem makensis.exe - is 32-bit. A runner running as SYSTEM has + rem %LOCALAPPDATA% under C:\Windows\system32\config\systemprofile, and + rem WOW64 redirection sends 32-bit processes reading System32 to + rem SysWOW64, so they cannot see their own directory: candle exits + rem 0x80131700 and makensis reports "Unable to start child process, + rem error 0x2". rem - rem NSIS is what the project ships for Windows upgrades anyway. To bring - rem the MSI back, run the runner as a normal user (whose LOCALAPPDATA is - rem outside System32) and restore --bundles msi,nsis. - cargo tauri build --bundles nsis + rem The build VM carries junctions from the SysWOW64 view of + rem systemprofile\AppData\Local\tauri and systemprofile\.cache to the + rem System32 originals, which makes the redirected view resolve. A + rem runner running as a normal user needs no such patch. + cargo tauri build --bundles msi,nsis - name: Collect artifacts run: | set "PATH=%USERPROFILE%\.cargo\bin;C:\Program Files\nodejs;%PATH%" mkdir artifacts + copy app\src-tauri\target\release\bundle\msi\*.msi artifacts\ || exit /b 1 copy app\src-tauri\target\release\bundle\nsis\*.exe artifacts\ || exit /b 1 dir artifacts\