Make the AppImage updatable, and drop the deb and rpm
Secret Scan / scan (push) Successful in 4s
Build App (Preview) / compute-version (pull_request) Successful in 4s
Secret Scan / scan (pull_request) Successful in 3s
Build App (Preview) / create-release (pull_request) Successful in 2s
Build App (Preview) / build-macos (pull_request) Successful in 2m43s
Build App (Preview) / build-windows (pull_request) Successful in 4m51s
Build App (Preview) / build-linux (pull_request) Successful in 5m19s
Build App (Preview) / prune-previews (pull_request) Successful in 1s

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
This commit is contained in:
2026-09-02 17:10:44 -07:00
co-authored by Claude Opus 5
parent a3bdf6f4da
commit 9fadfbc37a
7 changed files with 301 additions and 19 deletions
@@ -0,0 +1,56 @@
<?xml version="1.0" encoding="UTF-8"?>
<!--
AppStream metadata for the AppImage.
Without this an AppImage manager (Gear Lever, AppImageLauncher and the like)
can adopt the file but has nothing to show for it: no summary, no category,
no release history. appimagetool warns about its absence on every build.
The id matches `identifier` in tauri.conf.json and the .desktop basename, so
the desktop entry, the AppStream component and the AppImage all name the
same application. `@VERSION@` is substituted at build time.
-->
<component type="desktop-application">
<id>com.triple-c.desktop</id>
<metadata_license>CC0-1.0</metadata_license>
<project_license>MIT</project_license>
<name>Triple-C</name>
<summary>Run Claude Code sessions in isolated Docker containers</summary>
<description>
<p>
Triple-C sandboxes Claude Code inside per-project Docker containers, so an
agent can install packages, edit files and run commands without touching
the host. Each project gets its own container, its own credentials and its
own terminal sessions.
</p>
<p>Features:</p>
<ul>
<li>Per-project containers with persistent home and config volumes</li>
<li>Multiple terminal sessions per project, in one reorderable tab strip</li>
<li>Notes that can be sent straight into a running agent's prompt</li>
<li>Anthropic, AWS Bedrock, Ollama, llama.cpp and OpenAI-compatible backends</li>
<li>Remote access over a browser terminal, and speech-to-text input</li>
</ul>
</description>
<launchable type="desktop-id">Triple-C.desktop</launchable>
<categories>
<category>Development</category>
<category>Utility</category>
</categories>
<url type="homepage">https://github.com/shadowdao/triple-c</url>
<url type="bugtracker">https://github.com/shadowdao/triple-c/issues</url>
<provides>
<binary>triple-c</binary>
</provides>
<releases>
<release version="@VERSION@" date="@DATE@"/>
</releases>
<content_rating type="oars-1.1"/>
</component>