BlueGit

golden-age paperdoll-renderer

design: AppImage tooling hosted on BlueGit, no GitHub at CI run time (Tim t1032u)

timfa Grok Bot · pushed by timfa

Authored 2026-11-08 · 6 days ago

Hash
37ab536a9c34c340d07001077b254d276ada1e45
Parent
7571e5c9
Pipeline
Passed
1 file changed +9 −0
design.md +9 −0
@@ -601,3 +601,12 @@ Each layer has a setting *semi-transparency allowed*: the body in the `.ppd` (`r
601 601 The setting is part of the render contract: `render.json` has `semi_transparency`, so a run is only resumed with the same setting. The `.ppda` (format 5) records it per layer as `semi_transparency`. Older `.ppda` files without the field are treated as semi-transparent, which they were. The `.ppe` container goes to version 3 (versions 1–2 still load, with the setting off). The `.ppd` stays at version 4, which is not released yet and now carries the trim and semi-transparency settings.
602 602
603 603 The v0.1.4 tag (f26d9fa) was pushed before this addition. Its pipeline (#604) was stopped before the release and AUR jobs (the AppImage tool download failed with HTTP 504), so nothing was published for v0.1.4. Tags are never deleted or moved, so this feature ships in a later version.
604
605 ## Decision 2026-11-08 (Tim t1032u): appimagetool from BlueGit, not GitHub
606
607 The AppImage job doesn't download anything from GitHub at run time any more. Before, it got appimagetool 1.9.1 from GitHub, and appimagetool itself then fetched the unpinned `continuous` type2-runtime from GitHub. Both downloads failed with HTTP 504 on the v0.1.4 tag pipeline. Now the pinned files are release assets of the public BlueGit project `golden-age/appimage-tools`, release `appimagetool-1.9.1_runtime-20251108`:
608
609 - `appimagetool-x86_64.AppImage`: upstream AppImage/appimagetool 1.9.1, SHA-256 `ed4ce84f0d9caff66f50bcca6ff6f35aae54ce8135408b3fa33abfc3cb384eb0`.
610 - `runtime-x86_64`: upstream AppImage/type2-runtime release `20251108`, SHA-256 `2fca8b443c92510f1483a883f60061ad09b46b978b2631c807cd873a47ec260d`.
611
612 Both checksums match the digests that GitHub publishes for those release assets. `scripts/package/appimage.sh` downloads both from BlueGit, checks the SHA-256 values above (which are pinned in this repo), and calls appimagetool with `--runtime-file`, so appimagetool makes no network call. Both files are MIT-licensed, and the tools project keeps their licence texts. A new tool version means a new release in that project plus new pinned checksums here.
@@ -601,3 +601,12 @@ Each layer has a setting *semi-transparency allowed*: the body in the `.ppd` (`r
601The setting is part of the render contract: `render.json` has `semi_transparency`, so a run is only resumed with the same setting. The `.ppda` (format 5) records it per layer as `semi_transparency`. Older `.ppda` files without the field are treated as semi-transparent, which they were. The `.ppe` container goes to version 3 (versions 1–2 still load, with the setting off). The `.ppd` stays at version 4, which is not released yet and now carries the trim and semi-transparency settings.
601The setting is part of the render contract: `render.json` has `semi_transparency`, so a run is only resumed with the same setting. The `.ppda` (format 5) records it per layer as `semi_transparency`. Older `.ppda` files without the field are treated as semi-transparent, which they were. The `.ppe` container goes to version 3 (versions 1–2 still load, with the setting off). The `.ppd` stays at version 4, which is not released yet and now carries the trim and semi-transparency settings.
602
602
603The v0.1.4 tag (f26d9fa) was pushed before this addition. Its pipeline (#604) was stopped before the release and AUR jobs (the AppImage tool download failed with HTTP 504), so nothing was published for v0.1.4. Tags are never deleted or moved, so this feature ships in a later version.
603The v0.1.4 tag (f26d9fa) was pushed before this addition. Its pipeline (#604) was stopped before the release and AUR jobs (the AppImage tool download failed with HTTP 504), so nothing was published for v0.1.4. Tags are never deleted or moved, so this feature ships in a later version.
604
605## Decision 2026-11-08 (Tim t1032u): appimagetool from BlueGit, not GitHub
606
607The AppImage job doesn't download anything from GitHub at run time any more. Before, it got appimagetool 1.9.1 from GitHub, and appimagetool itself then fetched the unpinned `continuous` type2-runtime from GitHub. Both downloads failed with HTTP 504 on the v0.1.4 tag pipeline. Now the pinned files are release assets of the public BlueGit project `golden-age/appimage-tools`, release `appimagetool-1.9.1_runtime-20251108`:
608
609- `appimagetool-x86_64.AppImage`: upstream AppImage/appimagetool 1.9.1, SHA-256 `ed4ce84f0d9caff66f50bcca6ff6f35aae54ce8135408b3fa33abfc3cb384eb0`.
610- `runtime-x86_64`: upstream AppImage/type2-runtime release `20251108`, SHA-256 `2fca8b443c92510f1483a883f60061ad09b46b978b2631c807cd873a47ec260d`.
611
612Both checksums match the digests that GitHub publishes for those release assets. `scripts/package/appimage.sh` downloads both from BlueGit, checks the SHA-256 values above (which are pinned in this repo), and calls appimagetool with `--runtime-file`, so appimagetool makes no network call. Both files are MIT-licensed, and the tools project keeps their licence texts. A new tool version means a new release in that project plus new pinned checksums here.