feat(desktop): show the installed app's own version in the UI
Build desktop / desktop (push) Successful in 4m47s
Build & push images / images (push) Successful in 2m54s
CI / check (push) Successful in 42s

Nothing displayed which desktop build was actually installed — debugging
a stuck update meant inferring the current version backwards from the
update prompt's target version. Added DesktopVersionBadge (next to the
existing server-side VersionBadge) using @tauri-apps/api's getVersion(),
the real running app version baked in from tauri.conf.json. No-ops in a
browser. Exported inTauri() from origin.ts instead of redefining it again.
This commit is contained in:
2026-09-03 16:31:48 +02:00
parent 7804285dec
commit 56904422af
6 changed files with 50 additions and 2 deletions
+10
View File
@@ -178,6 +178,16 @@ Per the user's choices — the operator **keeps OS access** (no fullscreen lockd
together; a `resources.toml` change still needs a Komodo sync + Stack redeploy to take effect on
a live booth, it isn't automatic from a git push alone — and see [[fleet-deployment-komodo]] for
a real ResourceSync-branch gotcha this exact fix ran into.
- **No way to see the installed app's own version (found + fixed 2026-09-03).** `VersionBadge` in
`router.tsx` shows the *server's* `<branch>-<sha>` (from `/api/version`, gated `site:read`) — but
nothing showed the *desktop client's* own version. An operator debugging a stuck update had no way
to confirm which build was actually installed short of reading the update-available prompt's
target version and inferring backwards. Fixed with `DesktopVersionBadge`, next to `VersionBadge`:
calls `@tauri-apps/api/app`'s `getVersion()` (the real running app's version, baked in from
`tauri.conf.json` — synced to the git tag by `release.yml`, see the version-drift gotcha above),
no-ops/renders nothing in a browser (`inTauri()` guard, now exported from `origin.ts` instead of
redefined a 4th time). `@tauri-apps/api` added as an explicit dependency (was only ever transitive
via the plugins).
- **`VITE_API_BASE` — desktop vs. browser (regression found + fixed 2026-09-03):**
`apps/web/.env.production` (committed, shared by both builds) sets `VITE_API_BASE=` (empty) — this
is correct for the **browser/booth** build (Fastify same-origin, stays relative) since commit
+9
View File
@@ -2808,3 +2808,12 @@ and fixed a real, pre-existing Komodo ResourceSync misconfig (resource-sync-park
`dev`, not `stage`, silently reading resources.toml from the wrong branch for months with zero
effect until dev/stage first diverged today) — full writeup on [[fleet-deployment-komodo]], which
had already warned about exactly this gotcha back in 2026-07-07 and it happened anyway.
## [2026-09-03] feat | Desktop app version now visible in the UI (was invisible)
There was no way to see which desktop build was actually installed anywhere in the app — an
operator debugging a stuck update had to infer it backwards from the update prompt's target
version ("it's offering v0.1.4, so I must be on v0.1.3"). Added DesktopVersionBadge next to the
existing server-side VersionBadge in router.tsx, using @tauri-apps/api's getVersion() (the real
running app version, synced to the git tag at build time by release.yml). No-ops in a browser.
Full detail on [[desktop-shell-tauri]].