Commit Graph

5 Commits

Author SHA1 Message Date
697642fa4d ci(check): add svelte-check and workspace lib tests
svelte-check catches type/template errors Vite's build skips; cargo
test --workspace --lib runs our pure-unit suites (prompt contract,
hallucination filter, preset parsing) without GPU or runtime deps.
Test step is Linux-only so the Windows/macOS legs stay focused on
platform compile coverage.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-21 17:32:18 +01:00
Cursor Agent
2f763e124b fix(ci): set LIBCLANG_PATH on Linux; install Vulkan via brew on macOS
Some checks failed
check / cargo check (macos-latest) (push) Has been cancelled
check / cargo check (ubuntu-22.04) (push) Has been cancelled
check / cargo check (windows-latest) (push) Has been cancelled
check / svelte build + lint (push) Has been cancelled
Two follow-ups to the previous CI deps commit:

1. Linux: libclang-dev installs libclang.so under
   /usr/lib/llvm-*/lib and /usr/lib/x86_64-linux-gnu, but
   bindgen-0.72.1 does not probe the llvm-versioned directory by
   default. Resolve the newest /usr/lib/llvm-*/lib candidate
   dynamically and export LIBCLANG_PATH so bindgen finds it without
   any clang-sys guesswork. Also install glslang-tools + spirv-tools
   so find_package(Vulkan COMPONENTS glslc) succeeds against
   ggml-vulkan's cmake step.

2. macOS: llama-cpp-sys-2 sets GGML_VULKAN=ON unconditionally when
   the vulkan feature is enabled; cmake's find_package(Vulkan) then
   fails on a vanilla macOS-latest runner because there is no
   Vulkan SDK shipped by default. The LunarG macOS SDK ships as a
   non-scriptable interactive installer, so we compose MoltenVK +
   Vulkan loader + headers + shaderc via Homebrew formulae instead.
   Export VULKAN_SDK=$(brew --prefix) and CMAKE_PREFIX_PATH=same so
   both the build.rs branch and cmake's FindVulkan resolve headers /
   libs / glslc from /opt/homebrew.

Applied symmetrically to check.yml and build.yml. Windows config is
unchanged.

Co-authored-by: jars <jakejars@users.noreply.github.com>
2026-04-21 15:54:15 +01:00
Cursor Agent
db8f1bf19d fix(ci): install libclang + Vulkan SDK on all platforms
Both whisper-rs-sys and llama-cpp-sys-2 run bindgen at build time,
which requires libclang.so/dylib/dll resolvable from the loader.
None of the three GitHub runners ship this out of the box today:
  - ubuntu-22.04: bindgen-0.72.1 panics with 'couldn't find any
    valid shared libraries matching libclang.so*'
  - macos-latest: same panic against libclang.dylib
  - windows-latest: choco already installed llvm here, but libclang
    was on an unset LIBCLANG_PATH, so bindgen still couldn't find it

And llama-cpp-sys-2's vulkan feature (wired on by whisper-rs' vulkan
feature → whisper-rs-sys + its own shared ggml build) hard-panics on
Windows when VULKAN_SDK is unset, and needs libvulkan.so linkable on
Linux.

Changes, applied symmetrically to check.yml and build.yml:
  - Linux: add libclang-dev, clang, libvulkan-dev to apt-get install.
  - macOS: brew install llvm, set LIBCLANG_PATH to brew --prefix
    llvm /lib so bindgen can load libclang.dylib.
  - Windows: choco install vulkan-sdk, set VULKAN_SDK to the
    newest-version directory under C:\VulkanSDK (resolved
    dynamically so a minor-version bump doesn't hardcode-break
    anything), set LIBCLANG_PATH to the llvm bin dir.

Unblocks the per-push cargo check job on main, phase4-systems-f7d0,
and phase4-ux-f7d0; also unblocks the release build. The Windows
Vulkan SDK install is the new long pole (~2 min on a cold runner)
but is needed unconditionally while the vulkan feature is on in
crates/transcription/Cargo.toml.

Co-authored-by: jars <jakejars@users.noreply.github.com>
2026-04-21 15:54:15 +01:00
da74a84009 ci: point Swatinem/rust-cache at the real workspace root
Some checks failed
check / cargo check (macos-latest) (push) Has been cancelled
check / cargo check (ubuntu-22.04) (push) Has been cancelled
check / cargo check (windows-latest) (push) Has been cancelled
check / svelte build + lint (push) Has been cancelled
Both workflows had `workspaces: src-tauri -> target`, which tells
rust-cache the workspace lives at src-tauri/ and its target dir is
src-tauri/target. Neither is true: the workspace is defined at the repo
root (Cargo.toml:1–3 — members = ["src-tauri", "crates/*"]), so cargo
walks up and puts artifacts at ./target, not ./src-tauri/target.

Result: the cache action was saving an empty (or wrong) directory on
every run. Every CI run on every OS effectively started from a cold
build, which is the actual reason the Windows job appeared to compile
sqlx from scratch every push — it was compiling sqlx from scratch every
push.

Point the cache at the real workspace root. While here, drop the
`working-directory: src-tauri` on the cargo check step so the command
runs from the workspace root too; cargo finds the same workspace either
way, but running from root is consistent with the cache's view.

Expected impact: Windows check job drops from ~15–25 min cold-every-time
to ~2–3 min on warm runs, matching Linux/macOS behaviour.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-21 15:42:12 +01:00
7de2feb932 chore: add CI workflows, dev launcher, and linux capability schema
.github/workflows/check.yml: cargo check on Linux + Windows + macOS
  plus Svelte/Vite build on every push to main and every PR. Fast
  feedback without paying for the full release build.

.github/workflows/build.yml: cross-platform release build producing
  .AppImage/.deb (Linux), .msi/.exe (Windows), .dmg (macOS). Triggers
  on v* tag push (attaches to a draft GitHub Release) or manual
  workflow_dispatch. Signing stubs commented out pending cert decisions.

run.sh: dev launcher that starts Vite, waits for port 1420, then runs
  tauri dev with beforeDevCommand blanked to avoid a second Vite spawn.
  Restores tauri.conf.json on exit via trap.

src-tauri/gen/schemas/linux-schema.json: Tauri-generated capability
  schema for Linux; the other platform schemas (desktop, windows) were
  already committed. Adds the missing sibling.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-04-18 09:03:28 +01:00