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
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:
@@ -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>
|
||||
Reference in New Issue
Block a user