12 Commits

Include renames

Author	SHA1	Message	Date
shadowdaoandClaude Opus 5	d561ce03d5	Anchor the update channel tag, and stop shipping a duplicate AppImage ... Two defects in the update channel, both visible in 0.4.20 and 0.4.21. **The channel tag does not survive.** `publish-update-channel.sh` created the GitHub release, uploaded both assets and verified each URL returned 200 — the job log shows it succeeding at 00:38. By 13:04 the tag was gone and every installed copy was checking a 404. Gitea push-mirrors this repo to GitHub every four hours, and a mirror push deletes remote refs with no local counterpart. `linux-latest` was created by GitHub's release API and never existed as a Gitea tag, so the mirror removed it. Versioned tags were never affected because `create-tag` creates them in Gitea first. So the tag is now anchored in Gitea, and before the GitHub release rather than after, so there is no window where the two disagree. Its absence fails the step instead of warning, because it is the only thing keeping the channel alive. Worth stating plainly: publishing correctly is not evidence the channel still works, and the verification that passed at 00:38 could not have caught a failure that arrives twelve hours later. **Every release carried the AppImage twice.** The channel's stable-named copy sat beside the versioned one, where the release job's `*.AppImage` glob picked it up — so v0.4.21 published `Triple-C_0.4.21_amd64.AppImage` and `Triple-C_x86_64.AppImage`, byte-identical at 86,686,200 bytes each, and `sync-to-github` copied both to the mirror. 80 MB of duplicate per release, under a name that reads like a different build. That is how it was noticed. The channel pair now lives in `bundle/appimage/update-channel/`, out of the glob's reach, and a guard fails the build if more than one AppImage is left beside the release. Verified by planting a second one: it fails. One appimagetool quirk found while moving it — zsyncmake writes the .zsync into the working directory, not beside the image it describes, so it has to be collected rather than assumed in place. The existing guard caught that too. Verified against the real 0.4.19 artifact: exactly one AppImage at top level, the channel pair in its own directory, update string still resolving to the fixed tag, and the wayland fallback intact. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011YPqHpjV4EL6RNEwrRKqQm	2026-09-03 08:29:58 -07:00
shadowdaoandClaude Opus 5	9fadfbc37a	Make the AppImage updatable, and drop the deb and rpm ... An AppImage manager can adopt the current build but never update it: the image carries no update information, which is the string that tells such a tool where to look for a newer one. It also carries no AppStream metadata, so a manager has nothing to show but a filename — appimagetool has been warning about that on every build — and linuxdeploy leaves `Categories=` empty, which files the app nowhere in a desktop menu. All three are fixed while the image is already unpacked for the wayland fix, so the cost is a few lines rather than a second pass. `unbundle-wayland-client.sh` is now `finalize-appimage.sh`, since it does more than unbundle. The update URL is a **fixed** `linux-latest` tag on the GitHub mirror, which is where updates are pulled from — deliberately not `releases/latest`. `latest` follows whichever release is newest, and the Gitea-to-GitHub backfill creates one GitHub release per Gitea tag, including the `-win` and `-mac` tags that carry no AppImage. A URL that can resolve to a release with no AppImage in it fails on users' machines and nowhere else. The output is named for that tag too, and that is not cosmetic: zsync records a *relative* filename which a client resolves against the .zsync URL it fetched, so a versioned name would send every client after the build it already has. Verified by reading the generated header — `Filename: Triple-C_x86_64 .AppImage` — and the image's own `.upd_info` section, which is where the tag actually lives. My first guard checked the .zsync for the tag and failed correctly, which is how that distinction got found rather than shipped. Range requests were confirmed against the mirror before building on them: 206 with a correct content-range, so updates are real deltas rather than an 85 MB re-download. The .deb and .rpm go. They are two more artifacts to build, publish and keep working for an audience already served by the one file that runs on every distribution, and neither could ever self-update — which is now the difference that matters. Older releases keep theirs. The Linux job passes `--bundles appimage` rather than changing `tauri.conf.json`, so macOS and Windows are untouched. Verified against the real 0.4.19 artifact: it repacks, the AppStream file and filled-in Categories land inside the image, the update string resolves to the fixed tag, and the wayland fallback still holds. Both publisher failure paths refuse rather than half-publishing — no token, and missing artifacts. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011YPqHpjV4EL6RNEwrRKqQm	2026-09-02 17:10:44 -07:00
shadowdaoandClaude Opus 5	a3bdf6f4da	Let the host's libwayland-client win in the AppImage ... The AppImage came up blank on CachyOS with `Could not create default EGL display: EGL_BAD_PARAMETER. Aborting...`, and the DMA-BUF workaround already in `main.rs` did not help — verified by finding the flag compiled into the shipped 0.4.19 binary, where it runs unconditionally on Linux. It is a different fault with the same error text. linuxdeploy bundles `libwayland-client.so.0` as a GTK dependency and `AppRun.wrapped` puts the bundled directory ahead of the host's, so the host's Mesa resolves against our copy. `libEGL_mesa.so.0` — the driver libglvnd's `libEGL.so.1` dlopens — has a hard DT_NEEDED on that library, so when its symbols will not resolve the driver never loads, glvnd is left with none, and `eglGetDisplay` reports no display. That is why `GDK_BACKEND=x11` does not dodge it, and why the symptom is a bad-parameter error rather than a link failure. Bisected on the reporter's machine against the released artifact — removing `libwayland-client.so.0` from the AppDir cleared the abort, while removing `libwayland-egl` or `libepoxy` did not. The bundled copy (Ubuntu 22.04, wayland 1.20) is missing eleven symbols their wayland 1.26 exports, including `wl_proxy_get_display`, `wl_proxy_get_queue`, `wl_display_create_queue_with_name` and `wl_fixes_interface`. Bundling a newer wayland would defer this, not fix it: the floor is set by the host's Mesa, which updates independently of our releases, so any version we pick is one release away from being too old again. This is a host-coupled library like libGL and libdrm — the only correct version is the host's. So the copy is demoted rather than deleted. It moves off the loader path into `usr/lib/wayland-fallback`, and a hook adds that directory back only when the host has no libwayland-client of its own — so a host without one still starts. The ordering is safe because `AppRun.wrapped` appends the inherited LD_LIBRARY_PATH after its own entries, making the hook a fallback and never an override. AppRun sources hooks by name rather than globbing, so it is patched to source this one. X11-only hosts are unaffected: libwayland-client is a package dependency of Mesa and GTK, so it is present even on a machine with no display server at all — confirmed on a headless container with neither DISPLAY nor WAYLAND_DISPLAY set. And the AppImage already runs as an X11 client everywhere, since linuxdeploy's own hook forces GDK_BACKEND=x11. Verified against the real 0.4.19 artifact rather than a synthetic AppDir: it repacks, the binary and AppRun survive, and both hook branches were exercised — host-has-it leaves LD_LIBRARY_PATH untouched, and a debian:12-slim container with no wayland at all engages the fallback. The comment in `main.rs` quoted this exact error as one the DMA-BUF flag fixes. That claim sent this investigation down the wrong path first, so it is corrected rather than left to do it again. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011YPqHpjV4EL6RNEwrRKqQm	2026-09-02 16:57:51 -07:00
shadow-testandClaude Sonnet 5	945883bb9d	Actually offer a preview the release it precedes, and fix two more gaps ... An Opus review of the previous commit found its headline claim didn't hold: a preview and the release it precedes compute to the identical numeric version by construction, but check_for_updates compared with a strict `>` against the bare CARGO_PKG_VERSION (never the suffixed display string), so `(0,4,13) > (0,4,13)` is false and the release was never offered. Plain semver ordering doesn't make a `-preview.<sha>` suffix sort below the same numeric release on its own here, since the comparison never sees the suffix at all. pick_update now takes is_preview_build, derived from whether TRIPLE_C_BUILD_SUFFIX was baked in, and relaxes that one comparison to `>=` — so "a release exists at my own number" reads as an update. A production build still requires strictly newer. Also: ported build-app.yml's `git tag --points-at HEAD` guard into the preview version computation. Without it, workflow_dispatch (which this workflow allows on main, not just PR builds) run on a commit a release was already cut from would compute one past that release — reintroducing "preview outranks production" through the manual-dispatch door. And corrected two comments that claimed the prerelease filter was currently a no-op: backfill-releases.yml mirrors every Gitea release to GitHub unfiltered, prerelease flag included, so it's real defence-in-depth against a dispatched backfill leaking a preview release, not a no-op. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FGjXq6fqtAFHdbhk4f3PfZ	2026-08-27 10:24:24 -07:00
shadow-testandClaude Sonnet 5	b71e15c2c0	Make preview versions monotonic and distinguishable from production ... build-app-preview.yml computed its patch number as `git rev-list --count <latest tag>..HEAD` — the exact formula build-app.yml itself documents as broken and replaced (#26): a distance from whichever tag sorts highest, not a counter, so it resets to zero on every release and previews went backwards (0.4.62 -> 0.4.0) the moment one landed. Ported the same "one past the highest patch already used" computation build-app.yml uses for real releases, reading the same tags (including -mac/-win suffixes), so a preview built right before a release now computes the exact number that release is about to take — semver already orders `0.4.12-preview.<sha> < 0.4.12`, so a preview user is offered the release the moment it ships instead of being silently pinned forever. The installed preview's reported version was also indistinguishable from production: the bundle's own version field strips the `-preview.<sha>` suffix before touching tauri.conf.json/Cargo.toml/package.json, since the Windows MSI's ProductVersion has no room for one. Rather than risk that (unverifiable without an actual Windows build), preview builds now bake the suffix into the binary separately via a TRIPLE_C_BUILD_SUFFIX build-time env var, and get_app_version() appends it when present — a production build sets nothing, so this is a no-op there. Also: added `prerelease` to `GitHubRelease` and filter on it in check_for_updates (currently a no-op against real data — nothing mirrored to GitHub is ever prerelease:true — but the updater is no longer structurally incapable of enforcing a channel split if one is ever made explicit). And deleted sync-release.yml: workflow_dispatch-only, reading gitea.event.release.* fields a manual dispatch never populates, so it could never have actually run; build-app.yml's inline mirror already does the same job. Refactored check_for_updates' filtering into a pure, testable pick_update helper (this file had no tests before), and added tests for it and the new get_app_version suffix handling. Fixes #32. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FGjXq6fqtAFHdbhk4f3PfZ	2026-08-27 10:11:35 -07:00
shadow-testandClaude Opus 5	ab747ce53d	Say what "open in container" is doing, and land on the pane doing it ... Opening a page is a container probe, a browser launch, a page load and often a viewer start — several seconds during which the only feedback was the click itself. Worse from a terminal, where the result appears in a pane the user is not looking at. So: the backend emits progress on the existing `container-progress` channel at each step, the Browser tab renders that line whenever it is set — the progress belongs to the project, not to whoever pressed the button, which is what lets a terminal-initiated open report anywhere at all — and the terminal's "In container" now selects the project's Browser tab before starting, so the line has somewhere to appear. Selecting a sub-tab from outside needed a route: `ProjectHome` keeps it in local state, so `openProjectHomeTab` parks a request in the store and the pane consumes it once. Consumed once, so it cannot fight the user's own clicking afterwards. Preview releases now prune themselves to the newest KEEP_PREVIEWS (2), in a job that runs only if all three platforms published — a half-finished run must not evict a good older build. The cleanup workflow's manual sweep stays as the backstop. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-11 11:13:21 -07:00
shadow-testandClaude Opus 5	5bd80a05bc	One build per push: previews carry the PR check ... Every push to the PR started two workflows on the same commit. build-app.yml ran on pull_request and compiled all three platforms — then published nothing, because every publishing step in it is gated on `gitea.event_name == 'push'`. build-app-preview.yml compiled the same three and published them. Six OS builds per push, half of them unreachable. So the PR trigger moves to the preview workflow, which was already doing the identical compilation and has something to show for it. build-app.yml is now push-to-main and manual dispatch only: releases. Two things a pull_request event changes, handled rather than inherited: `gitea.sha` can be the merge ref — not the commit anyone is testing, and not something to hang a tag on — so the release's target comes from `git rev-parse HEAD` in the checkout; and `gitea.ref_name` is the PR number, so the release body uses `gitea.head_ref` when there is one. The cost is one prerelease per PR commit touching app/**, which the existing Cleanup Old Releases sweep already prunes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-11 10:41:35 -07:00
shadow-testandClaude Opus 5	5b18ce804f	Start the 0.4 line, and give previews the version they are previewing ... Two version problems, one of them mine. **Previews claimed x.y.0.** The preview workflow hard-coded the patch number, so every preview installer reported 0.3.0 whatever it contained, while the real build computes the patch from tags. It now runs the same computation, so a preview is labelled with the version the release it previews would carry. **A new minor line started at the wrong number.** `compute-version`'s fallback for "no tag matches this line yet" counted every commit in the repository — fine as a bootstrap, wrong the moment a minor version is bumped: the first 0.4 build would have been 0.4.234. A line nobody has tagged is a new line, and a new line starts at .0. With those fixed, VERSION moves to 0.4 — tab reordering, the browser pop-out, opening pages in the container's browser and the Playwright install fix are more than a patch bump. The next release is v0.4.0; today's HEAD would have been 0.3.90 on the old line. `app/package.json`, `package-lock.json`, `tauri.conf.json` and `Cargo.toml` follow to 0.4.0. CI patches all four per build, so they are the dev-time defaults rather than the source of truth — but a local `tauri dev` shows them, so they should not still say 0.3. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-11 10:06:00 -07:00
shadow-testandClaude Opus 5	63f3c54b95	Publish preview builds as a prerelease instead of workflow artifacts ... Workflow artifacts do not work on this Gitea, in two different ways: * upload-artifact@v4 cannot run at all. @actions/artifact v2's isGhes() treats any GITHUB_SERVER_URL that is not github.com / *.ghe.com / *.localhost as GitHub Enterprise Server and throws before making a single request. act_runner sets it to this instance, so all three platforms died with GHESNotSupportedError — after paying for the whole Tauri build (run #265). * @v3 uploads succeed and the files are downloadable by direct URL, but Gitea does not *list* them: /api/v1/…/runs/<id>/artifacts returns total_count 0 and the run page shows nothing (verified on run #267). A build nobody can find is not a build. So previews publish the way every other workflow here does: curl to the releases API. One prerelease per preview, tagged `preview-<sha>`, with all three platforms' bundles as assets — visible on the Releases page with stable links. The release is created in a job the three builds depend on rather than get-or-created in each. They run concurrently, so per-job creation races on one tag: the loser gets a 409, and the id parse then yields empty while the step still reports success — the failure build-app.yml's macOS job was hardened against after it happened for real. One creator removes the race instead of handling it. Asset upload keeps that hardening: delete-then-upload so a re-dispatch replaces rather than 409s, --http1.1 and retries for the mid-stream drops the macOS runner has produced (curl exit 92, exit 28), and an explicit failure when a platform produced no bundles at all. The `preview-` prefix is load-bearing: cleanup-releases.yml keeps recent `v<x>.<y>.<z>` releases and separately deletes every release whose tag does not start with `v[0-9]`, so previews are pruned by the cleanup already in use and never crowd the real release list. sync-release.yml is dispatch-only, so none of this reaches GitHub. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-11 09:38:06 -07:00
shadow-testandClaude Opus 5	1207a21aae	Pin the preview build's uploads to upload-artifact@v3 ... Run #265 — this workflow's first ever run — built the app on all three platforms and then lost every bundle at the upload step: GHESNotSupportedError: @actions/artifact v2.0.0+, upload-artifact@v4+ and download-artifact@v4+ are not currently supported on GHES. v4 bundles @actions/artifact v2, whose isGhes() treats any GITHUB_SERVER_URL that is not github.com, *.ghe.com or *.localhost as GitHub Enterprise Server and throws before making a single request. act_runner sets that variable to this Gitea instance, so v4 cannot work here on any runner or any OS — and it fails *after* the whole Tauri build has been paid for. v3 uses the v1 artifact API, which Gitea implements. Both options this workflow relies on, `if-no-files-found: error` and `retention-days`, exist in v3. The other workflows never hit this because they publish by curling the Gitea releases API instead. Noted at the top of the file, with the isGhes rule, so the pin is not "upgraded" back. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-11 08:00:06 -07:00
shadow-testandClaude Opus 4.7	5360f22b65	Make preview build workflow manual-only ... Trigger is workflow_dispatch exclusively so builds happen only when explicitly requested from the Actions UI, not on every branch push. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-24 10:22:11 -07:00
shadow-testandClaude Opus 4.7	0316234329	Add preview build workflow for non-main branches ... Mirrors build-app.yml's three-platform matrix (Linux/macOS/Windows) but uploads the bundles as workflow artifacts instead of creating Gitea releases or syncing to GitHub, so feature branches can be smoke-tested without cluttering the release streams. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-24 10:21:17 -07:00