Triple-C

Author	SHA1	Message	Date
jknapp	e05156fd0e	Merge branch 'main' into feature/model-backends-and-browser Build App / compute-version (pull_request) Successful in 3s Details Build Container / build-container (pull_request) Successful in 33s Details Build App / build-macos (pull_request) Successful in 2m30s Details Build App / build-windows (pull_request) Successful in 5m12s Details Build App / build-linux (pull_request) Successful in 7m40s Details Build App / create-tag (pull_request) Skipped Details Build App / sync-to-github (pull_request) Skipped Details	2026-08-10 06:13:40 +00:00
jknapp	aca6c49e3c	Merge pull request #13 : Drop MCP management; add permission modes, Project Home, Auth Bridge and shared auth Build App / compute-version (push) Successful in 11s Details Build Container / build-container (push) Successful in 1m45s Details Build App / build-macos (push) Successful in 2m29s Details Build App / build-windows (push) Successful in 5m6s Details Build App / build-linux (push) Successful in 6m31s Details Build App / create-tag (push) Successful in 3s Details Build App / sync-to-github (push) Successful in 10s Details Claude Code absorbed MCP natively, so Triple-C stops managing it. Also adds permission modes, Project Home, Tier-1 accessibility fixes, the Auth Bridge, shared Claude authentication and the scheduler UI. 8 commits plus review fixes. 87 frontend tests, 34 Rust tests.	2026-08-10 05:43:09 +00:00
shadow-testandClaude Opus 5	0aa8315514	CI: restore the MSI now that the 32-bit bundlers can resolve their paths Build App / compute-version (pull_request) Successful in 3s Details Build Container / build-container (pull_request) Successful in 32s Details Build App / build-macos (pull_request) Successful in 2m26s Details Build App / build-windows (pull_request) Successful in 4m51s Details Build App / build-linux (pull_request) Successful in 6m11s Details Build App / create-tag (pull_request) Skipped Details Build App / sync-to-github (pull_request) Skipped Details Dropping the MSI did not help: makensis.exe is 32-bit like candle.exe and failed the same way ("Unable to start child process, error 0x2"). The cause was WOW64 redirection sending 32-bit processes reading C:\Windows\System32 to SysWOW64, where the toolset directory does not exist. The build VM now carries junctions from the SysWOW64 view of systemprofile\AppData\Local\tauri and systemprofile\.cache to the System32 originals. Verified on the runner: candle.exe reports WiX 3.14.1.8722 and makensis reports v3.11, both exiting 0 from the path that previously failed. Both targets build again, so the .msi comes back. Artifact collection fails if either installer is missing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-09 22:34:59 -07:00
shadow-testandClaude Opus 5	fdc161fd9c	CI: build NSIS only on Windows, dropping the MSI target Build App / compute-version (pull_request) Successful in 17s Details Build Container / build-container (pull_request) Successful in 1m22s Details Build App / build-macos (pull_request) Successful in 2m22s Details Build App / build-windows (pull_request) Failing after 4m41s Details Build App / build-linux (pull_request) Successful in 5m51s Details Build App / create-tag (pull_request) Skipped Details Build App / sync-to-github (pull_request) Skipped Details WiX's candle.exe/light.exe are 32-bit. On a SYSTEM-run runner Tauri caches WiX under C:\Windows\system32\config\systemprofile\..., and WOW64 redirection sends 32-bit processes to SysWOW64 where that directory does not exist, so candle exits 0x80131700. Tauri aborts the whole bundle on one target's failure, so the MSI was suppressing the NSIS installer too and Windows produced no artifact at all. NSIS is what the project already relies on for Windows upgrades. Drops the .NET 3.5 gate, which existed only for WiX; keeps the MSVC step, which is what makes the app link. Artifact collection now fails when no installer is produced rather than tolerating an empty directory. To restore the MSI, run the runner as a normal user and set --bundles msi,nsis. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-09 22:24:42 -07:00
shadow-testandClaude Opus 5	763af91042	Revert: LOCALAPPDATA override does not move Tauri's WiX cache Build App / compute-version (pull_request) Successful in 3s Details Build Container / build-container (pull_request) Successful in 32s Details Build App / build-macos (pull_request) Successful in 2m23s Details Build App / build-windows (pull_request) Failing after 4m35s Details Build App / build-linux (pull_request) Successful in 5m6s Details Build App / create-tag (pull_request) Skipped Details Build App / sync-to-github (pull_request) Skipped Details Rust's `dirs` crate resolves LOCALAPPDATA on Windows through SHGetKnownFolderPath, which reads the process token rather than the environment, so the override changed nothing and 32-bit candle.exe still hit WOW64 redirection under the SYSTEM profile. Removing it rather than leaving a plausible-looking non-fix in the workflow. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-09 22:19:12 -07:00
shadow-testandClaude Opus 5	03384409e7	CI: keep the WiX toolset out of System32 so 32-bit candle.exe can run Build App / compute-version (pull_request) Successful in 13s Details Build Container / build-container (pull_request) Successful in 44s Details Build App / build-macos (pull_request) Successful in 2m24s Details Build App / build-windows (pull_request) Failing after 4m39s Details Build App / build-linux (pull_request) Successful in 6m44s Details Build App / create-tag (pull_request) Skipped Details Build App / sync-to-github (pull_request) Skipped Details WiX's candle.exe/light.exe are 32-bit. A SYSTEM-run runner has %LOCALAPPDATA% under C:\Windows\system32\config\systemprofile, where Tauri caches the WiX toolset — and WOW64 redirection sends 32-bit processes reading System32 to SysWOW64, which has no such directory. The CLR then fails to start with 0x80131700 and Tauri reports only "failed to run candle.exe". Verified: the same binary and identity exits 0 from C:\wixtest and 0x80131700 from the systemprofile path. Pointing LOCALAPPDATA outside System32 avoids redirection, needs no stored credential, and is a no-op for runners already running as a normal user. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-09 22:12:27 -07:00
shadow-testandClaude Opus 5	c6bb7fdf1d	CI: fix the MSVC exit-code check and verify .NET 3.5 before bundling Build App / compute-version (pull_request) Successful in 6s Details Build Container / build-container (pull_request) Successful in 1m48s Details Build App / build-windows (pull_request) Failing after 5m14s Details Build App / build-linux (pull_request) Successful in 6m2s Details Build App / build-macos (pull_request) Successful in 2m24s Details Build App / create-tag (pull_request) Skipped Details Build App / sync-to-github (pull_request) Skipped Details %VSEXIT% and %ERRORLEVEL% inside a parenthesised cmd block are substituted at parse time, not run time, so the installer's real exit code was never read. Uses delayed expansion now. Also checks for the .NET 3.5 runtime before building: WiX candle.exe needs it, and Tauri aborts the whole bundle when the MSI target fails, which silently suppresses the NSIS installer too. Fails early with the exact dism command rather than at bundle time. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-09 21:50:15 -07:00
shadow-testandClaude Opus 5	ca0f944712	CI: install MSVC build tools on Windows runners that lack them Build App / compute-version (pull_request) Successful in 4s Details Build Container / build-container (pull_request) Successful in 30s Details Build App / build-linux (pull_request) Successful in 5m24s Details Build App / build-windows (pull_request) Failing after 15m29s Details Build App / build-macos (pull_request) Successful in 2m24s Details Build App / create-tag (pull_request) Skipped Details Build App / sync-to-github (pull_request) Skipped Details build-windows failed on this PR with "linker `link.exe` not found", while build-linux and build-container passed — the code was fine, the runner environment was not. The job installs Rust and Node conditionally but assumed the MSVC C++ toolchain was hand-provisioned. A runner without it registers normally, advertises windows-latest, accepts the job, downloads the entire crate graph and only then fails at link time. That also means a bare runner coming online turns a job that would have queued for a capable machine into a failed build. Installs the VC++ workload when vswhere cannot find it, matching the existing conditional Rust and Node steps. rustc locates MSVC through vswhere and the registry rather than PATH, so no dev-shell activation is needed. Installer exit 3010 (success, reboot pending) is treated as success. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-09 19:36:14 -07:00

Compare commits

Diff Content Not Available