8 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5	13e48672c0	packaging: bare backticks — a heredoc's backslash isn't the JSON's ... Run 2981 built everything and then died posting the release: HTTP 422, "invalid escape sequence \`". The body's other backticks are written \` because they sit in an UNQUOTED heredoc, where that backslash is the shell's and is gone before any JSON exists. Copying the idiom into a single-quoted variable changed what it meant — single quotes already stop substitution, so the backslash survived into the body as an escape JSON has no rule for. bash -n passes either way; it checks syntax, not what a string becomes. So parse the assembled body for every branch it can take instead, and write down the recipe next to the one for formatting Rust. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MKsUY9Z45KQd34V956hZ9Q	2026-07-27 23:10:42 -04:00
bvandeusenandClaude Opus 5	d8b0cd9b96	packaging: the installer learns the same two channels the app updates on ... install.sh asked /releases/latest and installed whatever came back. That is v0.1.0 today, which predates the updater, and it was about to get worse: the `stable` pointer release write-manifest.sh creates is non-prerelease and holds only latest.json, so from the next v* tag onward it would have WON /releases/latest and the installer would have found nothing to install. So resolve a channel instead of a "latest". `--channel stable|dev` (or TS_CHANNEL), default stable, named to match update.rs's Channel exactly. dev reads /releases/tags/dev. stable reads the pointer's own latest.json, takes its version, and installs that v* release — the same file the app reads, so the installer and the updater cannot disagree about what stable means. Two things found on the way. The dev release's description still told people to run the stable command, and always would have: publish-release.sh writes a body only when it CREATES a release, and a fixed-tag release is only created once, so the text froze at the first build. The 409 path now PATCHes it. And the asset greps were unanchored, so a .AppImage.sig URL could match as the bundle URL — harmless by coincidence, not by construction. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MKsUY9Z45KQd34V956hZ9Q	2026-07-27 23:03:12 -04:00
bvandeusenandClaude Opus 5	d6734cf7a0	desktop: in-app updates, two channels, signed, fed by fixed-tag releases ... There was no in-place update anywhere. The app never checked, downloaded or applied anything, and the only published release predates the whole sync arc — so `install.sh` would hand out a build with no sync in it. Installing from per-run CI artifacts, which is what's been happening, is not something an updater can point at: ephemeral, auth-gated, no stable URL. Two channels, switchable in the app: `stable` follows tagged releases, `dev` follows every green push. The feed is a Fabled-Git release asset, not a ThoughtSync server route. This reverses the lean recorded in task 1998, and the reason matters — a server-hosted feed can only reach a desktop that has linked a server, and local-first-with-no-server is the whole premise. An unlinked install has to be able to update itself. Each channel reads a `latest.json` on a release whose TAG NEVER MOVES. That's forced, not stylistic: Forgejo has no /releases/latest/download/<asset> route (verified — it 404s with no redirect), so "newest" cannot be named in a URL. `dev` carries the rolling bundles; `stable` is a pointer release holding only the manifest, whose URLs aim at the versioned release's assets, so nothing is duplicated. The manifest is written by a third job that runs after both bundle jobs. They build in separate workspaces and neither can see the other's output, but one manifest has to describe both platforms — generating it inside either job would silently omit the other, and a missing platform reads to a user as "no update available" rather than as a broken feed. It reads what actually landed on the release, so it can never advertise a bundle that failed to upload. Signing is gated on the secret existing, in the script rather than an `if:` (the secrets context isn't reliably available to step conditions). No key means no updater artifacts and no publish: a feed the app would refuse to verify is worse than no feed, because it looks like it works. CI stays green until the key lands. On Linux the updater can only replace an AppImage — a deb or pacman install is owned by its package manager and must never be overwritten underneath it. The app detects that case up front and says so, instead of failing halfway through with a permissions error nobody can read. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SreJkbxB4gx8pPsu8QbLPi	2026-07-26 19:03:12 -04:00
bvandeusenandClaude Opus 5	ab961f13ce	desktop: cross-compiled Windows NSIS installer lane (task 2015) ... Adds a `windows` job to desktop.yml on the new ci-tauri-win image, producing a Windows -setup.exe without any Windows hardware. A Windows container can't run on a Linux host, so cross-compilation is the only route: --runner cargo-xwin supplies the MSVC CRT/SDK (pre-warmed into the image) and links with lld-link, and makensis builds the installer. NSIS only. .msi needs WiX v3, a Windows program — per Tauri, ".msi installers can only be created on Windows". It comes back if a Windows node ever exists. Kept as a separate job so a Windows-side failure can never block the Linux artifacts, which are the primary product today. publish-release.sh now globs the windows target root too; nullglob means each job uploads only what its own workspace contains, and the release is created once and reused via the 409 path, so both jobs can publish to the same release safely. No app code changes were needed. The AppImage self-integration UI already gates on is_appimage (AccountView.vue:131, DesktopIntegrationPrompt.vue:22), and $APPIMAGE is never set on Windows, so the OOBE prompt and Settings toggle hide themselves. Recorded plainly in ci-requirements.md that this is the weakest-verified lane we have: Tauri calls Linux->Windows cross-compilation "not tested as much" and a last resort, and a Linux runner cannot execute a Windows binary. Green means it built. A real Windows machine check is mandatory before trusting a release, and installers are unsigned until a certificate exists. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SreJkbxB4gx8pPsu8QbLPi	2026-07-25 20:14:55 -04:00
bvandeusenandClaude Opus 5	dc68386d1a	desktop: point the install command at a branch that exists ... The advertised curl URL referenced raw/branch/main, but main has never been created (creating it is rejected by a branch-protection rule that matches the name even with no branch behind it), so the one-command install 404'd. dev is currently the repo's only branch and serves the script fine now that the repo is public — verified 200, with all three v0.1.0 release assets resolving and the AppImage downloading in full. Flagged in the header to move back to main once that branch exists, so the public install command stops tracking day-to-day work. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SreJkbxB4gx8pPsu8QbLPi	2026-07-25 19:19:05 -04:00
bvandeusenandClaude Opus 5	85ca7c2a2d	desktop: drop the redundant deb depends, correct the pacman docs ... Follow-up to 8a8b2b1, driven by what run 2872's new checks actually printed. The .deb verification did its job on its first run: tauri already infers exactly libwebkit2gtk-4.1-0 + libgtk-3-0, so declaring the same two in tauri.conf.json produced a control file listing each of them twice. Removed the declaration — verify.sh is the real guard, and it fails the build if inference ever stops covering what the binary links. The pacman step revealed ci-tauri carries neither zstd nor bsdtar, so packages currently ship as .pkg.tar.xz with no .MTREE. Both are working outcomes (pacman reads xz; only `pacman -Qkk` needs .MTREE), but the docs promised .zst, so the README, the release notes and ci-requirements.md now describe what the build actually produces. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SreJkbxB4gx8pPsu8QbLPi	2026-07-25 18:26:24 -04:00
bvandeusenandClaude Opus 5	8a8b2b17e6	desktop: prebuilt pacman package + verified .deb (tasks 2022, 2074) ... Native packages the installer can actually fetch, before task 2014 wires up the fetching. Arch (task 2022, re-scoped): the source PKGBUILD is gone — asking every user to install rust+node and compile for minutes isn't distribution. Replaced by desktop/packaging/arch/package-prebuilt.sh, which wraps the binary the Linux job already built into a .pkg.tar.zst. No second Rust build, no Arch CI image: the binary bundles nothing and resolves webkit/gtk/soup by soname, identical on both distros, with SQLite compiled in and glibc used in the safe built-old/run-new direction. CI is Debian and has no pacman, so the step logs .PKGINFO plus the full file listing for audit instead of pretending to verify. Debian (task 2074): install.sh hands the .deb to every Debian/Ubuntu user and nothing had ever inspected it. tauri.conf.json now declares libwebkit2gtk-4.1-0 + libgtk-3-0 explicitly rather than trusting inference — and deliberately declares no appindicator or sqlite dep, since tauri is built with features=[] and rusqlite is "bundled". desktop/packaging/deb/verify.sh prints the generated control file, cross-checks it against what the ELF actually needs via dpkg-shlibdeps, confirms every declared dep exists in apt, and clean-container installs when a docker CLI is available. Both artifacts join the run artifact and the tagged release; install.sh grows a pacman branch so Arch/CachyOS gets a native install instead of the AppImage fallback. Still no release cut (rule 2). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SreJkbxB4gx8pPsu8QbLPi	2026-07-25 18:19:30 -04:00
bvandeusenandClaude Opus 4.8	36c05f5029	desktop: release-publish pipeline + one-command Linux installer ... Phase A of the desktop Release + install path (M10 / tasks 2014, 1998): - .forgejo/workflows/desktop.yml: tag-gated "Publish release" step + contents:write. On a v* tag the build now publishes a Fabled-Git Release with the de-bundled AppImage + .deb attached — a stable, versioned fetch target (Actions artifacts are ephemeral/test-only). Dormant on dev/main. - desktop/packaging/publish-release.sh: creates/reuses the Release via the Forgejo API using the runner-injected token; idempotent asset replace. - desktop/packaging/install.sh: curl|sh one-command installer — native .deb on Debian/Ubuntu, de-bundled AppImage everywhere else (installed to ~/Applications/ThoughtSync.AppImage, matching src/integration.rs so the app sees itself integrated). AppImage path needs no sudo. Plumbing only — no release cut (rule 2); activates on the operator's first v* tag. In-app self-update (tauri-plugin-updater + signed latest.json) is Phase B, gated on the operator's signing key. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FRgehjoz7Yv8LkUfADxACm	2026-07-25 14:13:50 -04:00