Files
thoughtsync/desktop
bvandeusen 43ebb6eceb
Desktop (Tauri) / Windows installer (cross-compiled) (push) Successful in 2m21s
Desktop (Tauri) / Tauri desktop (Linux) (push) Successful in 4m18s
Desktop (Tauri) / Update manifest (push) Successful in 4s
packaging: the rolling-release prune was eating the Android client
Run 4092 published `thoughtsync.apk` to the `dev` release. Run 4098 removed it,
four minutes later, and both runs were green.

`write-manifest.sh` prunes the rolling channel to stop ~100 MB AppImages
accumulating forever, keeping `latest.json` and anything whose name contains the
current `$APP_VERSION`. The Android assets deliberately have no version in their
names — a fixed name is the only addressable URL on a tag that never moves,
which is the entire reason the `dev` release exists — so they matched neither
rule and were swept.

They would have been swept even if they HAD carried a version: Android is a
different workflow with its own run number, so its version never equals the
desktop's `$APP_VERSION` in this script.

The keep-list is now about fixed names rather than about `latest.json`
specifically, which is what the rule always meant. A fixed-name asset is
self-limiting — each publish replaces the same name — so the accumulation this
prune exists to prevent cannot happen to one.

Worth noting how this presented: two green runs and a missing file. Nothing
failed, and the only way to see it was to ask the release what it actually held
rather than trusting that a step named "Publish" had published.
2026-08-20 20:31:03 -04:00
..

ThoughtSync desktop (Tauri v2)

Local-first desktop client. The window loads the shared Vue 3 frontend from ../frontend; the Rust core (src-tauri) owns the on-device store and the opt-in sync engine (built out across the M10 milestone). Works fully offline; optionally syncs to a self-hosted ThoughtSync server.

Layout

desktop/
  src-tauri/
    Cargo.toml
    build.rs
    tauri.conf.json          # frontendDist -> ../../frontend/dist, devUrl :5173
    capabilities/default.json
    src/
      main.rs                # thin shim -> lib::run()
      lib.rs                 # tauri::Builder entry point

The Vue frontend is the sibling ../frontend package, shared with the web build. On desktop it is backed by a local data source via frontend/src/adapters/ (M10.3) instead of the server REST API. frontend and src-tauri are siblings, not nested, so the beforeDev/beforeBuild commands cd "$(git rev-parse --show-toplevel)/frontend" to resolve regardless of the CLI's working directory.

Prerequisites

The toolchain (Rust + Node + WebKitGTK 4.1 + tauri-cli) is provided by the ci-tauri CI image. For local dev: install Rust + Node, cargo install tauri-cli, and the Tauri v2 Linux system deps — see CI-tauri/Dockerfile in the CI-runner repo for the exact apt list (libwebkit2gtk-4.1-dev, libgtk-3-dev, librsvg2-dev, libayatana-appindicator3-dev, libxdo-dev, patchelf, ...).

Dev

cd desktop/src-tauri && cargo tauri dev

beforeDevCommand starts the Vite dev server (port 5173) in ../frontend.

Build (Linux)

cargo tauri icon "$(git rev-parse --show-toplevel)/frontend/public/icon.svg"
cd desktop/src-tauri && cargo tauri build   # -> .deb + .AppImage

App icons are generated from the frontend's icon.svg via cargo tauri icon (not committed; CI does this before cargo tauri build). Bundle targets: deb, appimage (Linux-first; Windows/macOS later, no code changes expected).

Status

Scaffold (M10.2): boots the shared Vue UI in a native window. Until the local data adapter lands (M10.3 + M10.5) the app has no server configured, so it shows the login screen without a working backend — full offline functionality arrives with the local SQLite store (M10.4) + adapters/local.ts (M10.5).