mirror of
https://github.com/jamiepine/voicebox.git
synced 2026-09-15 04:40:40 -07:00
5964af5dea
* feat(ci): re-enable Linux release builds (CPU, deb+rpm) Linux shipped briefly in March 2026 (b580189..103e98b) then was removed with the message "github runners suck." The post-mortem: standard ubuntu-22.04 hit disk-pressure during pip+PyInstaller, and a namespace custom-runner attempt proved flaky. Nothing in the app itself was the problem — the NVIDIA-package exclusions in build_binary.py (~3 GB shaved from CPU builds), the CPU-only torch install order, the PulseAudio/PipeWire audio capture code, and the Tauri deb/rpm bundle targets all still work. This restores ubuntu-22.04 to the release matrix as a CPU-only Linux build with a disk-space cleanup step (jlumbroso/free-disk-space) to address the root cause of the March failures. Ships .deb + .rpm only — AppImage was explicitly dropped ine18757bdue to glibc portability issues, keeping that decision. CUDA-for-Linux is intentionally deferred to a follow-up PR: the GpuAcceleration.tsx frontend hard-codes CUDA download as Tauri-only without a Linux branch, and AMD users already get ROCm acceleration for free on a stock CPU-torch install (backend/app.py:148-160). The NVIDIA-on-Linux case is the only remaining gap and is non-blocking for a v1 Linux ship. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]> * chore(release): bump version 0.4.1 → 0.4.2 tauri-action uses tauri.conf.json's version to name the release, so pushing v0.4.2 as a tag alone was insufficient — the workflow was still trying to publish to v0.4.1 (immutable) and failing. Bumps all workspace package.json files, Cargo.toml, Cargo.lock, and tauri.conf.json. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]> * ci(release): add Linux bundle-step watchdog + verbose cargo logging The first v0.4.2 attempt hung inside tauri-action at the bundling stage on ubuntu-22.04 for ~28 min with no output. Same failure mode that drove the March 2026 removal (commit103e98b). Without visibility we're guessing — probable causes include linuxdeploy/AppImage download stalls (despite --bundles deb,rpm), cargo link on a cold cache, or disk pressure during the final link step. - timeout-minutes: 30 on tauri-action for Ubuntu (45 min elsewhere) — fail fast with logs instead of waiting out the 6hr job timeout. - --verbose added to the Linux build args so cargo streams progress. - CARGO_TERM_VERBOSE + RUST_BACKTRACE=1 exported on tauri-action. - New 'Disk / environment snapshot' step dumps df/free/tool versions right before the tauri step so we can correlate with any later OOM/ENOSPC failure. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]> * ci(release): disable Tauri updater artifacts on Linux (stops linuxdeploy hang) Round-2 diagnosis from the v0.4.2 attempt: cargo finished in 3m 55s, .deb and .rpm were bundled within 22s, then the step hung silently for 25 min until our 30-min watchdog killed it — no further log lines. tauri.conf.json has `createUpdaterArtifacts: "v1Compatible"`. On Linux the v1-compatible updater path wants a .AppImage.tar.gz, which means downloading linuxdeploy-x86_64.AppImage from GitHub at build time. That download is the silent blocker — same signature as the March 2026 "github runners suck" removal (commit103e98b). Fix: pass `--config {"bundle":{"createUpdaterArtifacts":false}}` on the Linux build only. Mac/Windows continue to produce signed updater artifacts as before. Linux users update via apt/dnf; Tauri in-app auto-update for Linux can come later (and would require shipping AppImage alongside deb/rpm). Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]> * ci(release): pin free-disk-space action + stop removing LLVM Review feedback on the Linux release workflow: 1. `jlumbroso/free-disk-space@main` was an unpinned ref in a job that runs with `contents: write` and handles signing secrets. Pin to the v1.3.1 commit SHA so a force-push or repo compromise can't inject arbitrary code into our release flow. 2. `large-packages: true` runs `apt-get remove '^llvm-.*'`, wiping LLVM just before the next step installs `llvm-dev`. That wastes CI time and risks cascade-removal of reverse deps that won't be pulled back in by `llvm-dev` alone. The remaining toggles (android, dotnet, haskell, swap-storage) already clear ~20 GB, which is enough headroom for the Python + torch + PyInstaller build. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]> --------- Co-authored-by: Claude Opus 4.7 (1M context) <[email protected]>