Smaller/faster godot-ci image (map) #2

New Issue

2026-08-06T20:28:11Z

haylan commented

2026-08-06 20:28:11 +00:00

Destination

A godot-ci image that is meaningfully smaller and faster to build than today's
barichello/godot-ci-based one (image size and CI build time both matter, roughly equally),
while still supporting everything it does today: Linux export, Windows cross-export
(mingw-w64), and Blender .blend import. Alpine/musl is a candidate base, not a locked
requirement — land on whichever approach (Alpine, a trimmed/multi-stage Debian or Ubuntu build,
or something else) the evidence actually supports. Android export is explicitly not in scope
(not in the current image, not requested).

Reference: abarichello/godot-ci's own Dockerfile builds Godot from the official
downloads.tuxfamily.org/github.com/godotengine/godot-builds releases directly (unzip the
editor binary to /usr/local/bin/godot, unpack export templates to
~/.local/share/godot/export_templates/<version>.<release>) rather than depending on any base
image doing that for it — useful precedent regardless of which base OS this effort lands on.

Notes

Domain: Docker image build for a Godot CI export toolchain (this repo, haylan/godot-ci).
Current image: see Dockerfile and README.md in this repo, and
docs/handoff/godot-ci-custom-image.md for the original scope rationale (that spec is itself
the artifact of a prior wayfinder map — issues #158/#162 in haylan/Project4x).
musl (Alpine) vs glibc (Ubuntu/Debian) compatibility is the central risk: official Godot editor
binaries, official Blender tarballs, and glibc-linked toolchains are not guaranteed to run
as-is under musl.
scripts/resolve-godot-version.sh and scripts/resolve-blender-url.sh are load-bearing for
the nightly auto-tracking workflow (.gitea/workflows/publish.yml) — any base-image change
that stops depending on barichello/godot-ci tags affects resolve-godot-version.sh
specifically, since it currently resolves barichello's published tags, not Godot's own
releases.
Consult /grilling and /domain-modeling for ticket resolution unless a ticket's type says
otherwise.

Decisions so far

Which base/approach wins: Alpine, trimmed Debian/Ubuntu, or slimming barichello? (#7)
— debian:bookworm-slim, dropping barichello/godot-ci entirely (Godot downloaded directly
from official godot-builds releases). Alpine and a bare glibc-slim swap were both rejected;
the actual win was shedding barichello's Android SDK/NDK weight, not the base OS per se.
Verified: 2343MB full image vs. barichello's bare base alone at 2460MB. Implemented on branch
feat/debian-slim-base (commit 8feeb2b), not yet merged/published.
Measure where current image's size/build-time actually go (#3)
— closed as redundant; its measurement got captured directly while resolving #7 instead.
Do official Godot Linux binaries run under Alpine/musl? (#4)
— no, glibc-only, no static/musl build; gcompat unconfirmed (open Godot issue reports a musl
segfault).
Does official Blender run under Alpine/musl? (#5)
— no, official tarball doesn't run as-is; musl-native blender-headless exists only on
Alpine's unpinned edge repo.
Is a working mingw-w64 toolchain available on Alpine? (#6)
— available, posix-threads-only, but again only on Alpine edge, untested for Godot builds.
Is a glibc-based slim distro a better fit than Alpine? (#8)
— debian:bookworm-slim clears every capability gap Alpine hit, but isn't meaningfully
smaller than ubuntu:noble on its own (~5% difference).

Not yet specified

(empty — the remaining route to the destination is fully ticketed: see the open child issues.)

Out of scope

Android export support — not in the current image, not requested for this effort.

## Destination A `godot-ci` image that is meaningfully smaller and faster to build than today's `barichello/godot-ci`-based one (image size and CI build time both matter, roughly equally), while still supporting everything it does today: Linux export, Windows cross-export (`mingw-w64`), and Blender `.blend` import. Alpine/musl is a candidate base, not a locked requirement — land on whichever approach (Alpine, a trimmed/multi-stage Debian or Ubuntu build, or something else) the evidence actually supports. Android export is explicitly not in scope (not in the current image, not requested). Reference: `abarichello/godot-ci`'s own Dockerfile builds Godot from the official `downloads.tuxfamily.org`/`github.com/godotengine/godot-builds` releases directly (unzip the editor binary to `/usr/local/bin/godot`, unpack export templates to `~/.local/share/godot/export_templates/<version>.<release>`) rather than depending on any base image doing that for it — useful precedent regardless of which base OS this effort lands on. ## Notes - Domain: Docker image build for a Godot CI export toolchain (this repo, `haylan/godot-ci`). - Current image: see `Dockerfile` and `README.md` in this repo, and `docs/handoff/godot-ci-custom-image.md` for the original scope rationale (that spec is itself the artifact of a prior wayfinder map — issues #158/#162 in `haylan/Project4x`). - musl (Alpine) vs glibc (Ubuntu/Debian) compatibility is the central risk: official Godot editor binaries, official Blender tarballs, and glibc-linked toolchains are not guaranteed to run as-is under musl. - `scripts/resolve-godot-version.sh` and `scripts/resolve-blender-url.sh` are load-bearing for the nightly auto-tracking workflow (`.gitea/workflows/publish.yml`) — any base-image change that stops depending on `barichello/godot-ci` tags affects `resolve-godot-version.sh` specifically, since it currently resolves *barichello's* published tags, not Godot's own releases. - Consult `/grilling` and `/domain-modeling` for ticket resolution unless a ticket's type says otherwise. ## Decisions so far - [Which base/approach wins: Alpine, trimmed Debian/Ubuntu, or slimming barichello? (#7)](https://git.arthurerlich.de/haylan/godot-ci/issues/7) — `debian:bookworm-slim`, dropping `barichello/godot-ci` entirely (Godot downloaded directly from official godot-builds releases). Alpine and a bare glibc-slim swap were both rejected; the actual win was shedding barichello's Android SDK/NDK weight, not the base OS per se. Verified: 2343MB full image vs. barichello's bare base alone at 2460MB. Implemented on branch `feat/debian-slim-base` (commit `8feeb2b`), not yet merged/published. - [Measure where current image's size/build-time actually go (#3)](https://git.arthurerlich.de/haylan/godot-ci/issues/3) — closed as redundant; its measurement got captured directly while resolving #7 instead. - [Do official Godot Linux binaries run under Alpine/musl? (#4)](https://git.arthurerlich.de/haylan/godot-ci/issues/4) — no, glibc-only, no static/musl build; `gcompat` unconfirmed (open Godot issue reports a musl segfault). - [Does official Blender run under Alpine/musl? (#5)](https://git.arthurerlich.de/haylan/godot-ci/issues/5) — no, official tarball doesn't run as-is; musl-native `blender-headless` exists only on Alpine's unpinned `edge` repo. - [Is a working mingw-w64 toolchain available on Alpine? (#6)](https://git.arthurerlich.de/haylan/godot-ci/issues/6) — available, posix-threads-only, but again only on Alpine `edge`, untested for Godot builds. - [Is a glibc-based slim distro a better fit than Alpine? (#8)](https://git.arthurerlich.de/haylan/godot-ci/issues/8) — `debian:bookworm-slim` clears every capability gap Alpine hit, but isn't meaningfully smaller than `ubuntu:noble` on its own (~5% difference). ## Not yet specified (empty — the remaining route to the destination is fully ticketed: see the open child issues.) ## Out of scope - Android export support — not in the current image, not requested for this effort.

haylan added the wayfinder:map label 2026-08-06 20:28:11 +00:00