haylan/godot-ci
1
0
Fork 0
Code Issues 3 Pull Requests Actions Packages Projects Releases Wiki Activity

Which base/approach wins: Alpine, trimmed Debian/Ubuntu, or slimming barichello? #7

New Issue
Closed
opened 2026-08-06 20:29:03 +00:00 by haylan · 1 comment
haylan commented 2026-08-06 20:29:03 +00:00
Owner
Copy Link
Copy Source

Question

Given the measured size/build-time breakdown (Measure where current image's size/build-time
actually go (#3)) and the musl-compatibility
findings for Godot (#4), Blender
(#5), and mingw-w64
(#6) — plus the glibc-slim-alternative
findings (#8) — which approach actually
delivers the win?

  • Alpine base, building the Godot CLI toolchain manually (per abarichello/godot-ci's own
    approach: download official binaries directly rather than depending on a base image for them),
    with gcompat if the research tickets show it's needed for Blender/Godot. Early signal from
    #4/#5/#6: everything this needs lives on Alpine's unpinned edge/community repos, and
    Godot/Blender musl compatibility is unverified (one open Godot issue reports a musl segfault)
    — this candidate is looking weak.
  • A glibc-based slim distro (e.g. debian:bookworm-slim) — same manual-toolchain approach as
    Alpine, but without the musl-compatibility risk. See #8.
  • A trimmed / multi-stage Debian or Ubuntu build (e.g. debian:slim, discard build-essential
    and dev headers after compiling export templates, keep only runtime .sos) — no libc risk, but
    a smaller size win.
  • Staying on barichello/godot-ci but slimming what's layered on top of it.
  • Anything else the research surfaces.

Blocked by #3,
#4,
#5,
#6,
#8.

Part of Smaller/faster godot-ci image (map).

## Question Given the measured size/build-time breakdown ([Measure where current image's size/build-time actually go (#3)](https://git.arthurerlich.de/haylan/godot-ci/issues/3)) and the musl-compatibility findings for Godot ([#4](https://git.arthurerlich.de/haylan/godot-ci/issues/4)), Blender ([#5](https://git.arthurerlich.de/haylan/godot-ci/issues/5)), and mingw-w64 ([#6](https://git.arthurerlich.de/haylan/godot-ci/issues/6)) — plus the glibc-slim-alternative findings ([#8](https://git.arthurerlich.de/haylan/godot-ci/issues/8)) — which approach actually delivers the win? - Alpine base, building the Godot CLI toolchain manually (per `abarichello/godot-ci`'s own approach: download official binaries directly rather than depending on a base image for them), with `gcompat` if the research tickets show it's needed for Blender/Godot. **Early signal from #4/#5/#6: everything this needs lives on Alpine's unpinned `edge`/`community` repos, and Godot/Blender musl compatibility is unverified (one open Godot issue reports a musl segfault) — this candidate is looking weak.** - A glibc-based slim distro (e.g. `debian:bookworm-slim`) — same manual-toolchain approach as Alpine, but without the musl-compatibility risk. See #8. - A trimmed / multi-stage Debian or Ubuntu build (e.g. `debian:slim`, discard `build-essential` and dev headers after compiling export templates, keep only runtime `.so`s) — no libc risk, but a smaller size win. - Staying on `barichello/godot-ci` but slimming what's layered on top of it. - Anything else the research surfaces. Blocked by [#3](https://git.arthurerlich.de/haylan/godot-ci/issues/3), [#4](https://git.arthurerlich.de/haylan/godot-ci/issues/4), [#5](https://git.arthurerlich.de/haylan/godot-ci/issues/5), [#6](https://git.arthurerlich.de/haylan/godot-ci/issues/6), [#8](https://git.arthurerlich.de/haylan/godot-ci/issues/8). Part of [Smaller/faster godot-ci image (map)](https://git.arthurerlich.de/haylan/godot-ci/issues/2).
haylan added the wayfinder:grilling label 2026-08-06 20:29:03 +00:00
haylan commented 2026-08-06 21:12:09 +00:00
Author
Owner
Copy Link
Copy Source

Answer

Decided: debian:bookworm-slim, dropping barichello/godot-ci as a base entirely — Godot
downloaded straight from official godot-builds releases (per abarichello's own approach), matching
candidate 2 from this ticket's options.

Why: #4/#5/#6 showed Alpine's compatibility risk was real and unresolved (glibc-only official
Godot/Blender binaries, Alpine's musl-native alternatives stuck on the unpinned edge repo). #8
showed a bare glibc-slim swap (Ubuntu → Debian) wasn't meaningfully smaller on its own. But
barichello/godot-ci's actual weight turned out to be mostly Android SDK/NDK (~2.4GB base, before
this repo's own layers) — weight this image never used (no Android export in scope). Dropping that
dependency entirely, not just swapping its base OS, is where the real win was.

Verified with a real local docker build + docker run: final image (Godot 4.7.1 + export
templates + Blender 4.2.3 + mingw-w64-posix + X11/audio dev libs) = 2343MB total, vs.
barichello/godot-ci:4.7.1's bare base alone = 2460MB (before any of this repo's packages were
added). Godot runs headless, export templates are present, x86_64-w64-mingw32-gcc-posix is the
active alternative, Blender runs — all smoke-tested in the built image.

Implemented on branch feat/debian-slim-base (commit 8feeb2b), not yet merged/published.

Supersedes the planned use of ticket #3's measurement (that data got captured directly as part of
resolving this ticket instead of as a separate session) — closing #3 as redundant.

## Answer **Decided: `debian:bookworm-slim`**, dropping `barichello/godot-ci` as a base entirely — Godot downloaded straight from official godot-builds releases (per abarichello's own approach), matching candidate 2 from this ticket's options. Why: #4/#5/#6 showed Alpine's compatibility risk was real and unresolved (glibc-only official Godot/Blender binaries, Alpine's musl-native alternatives stuck on the unpinned `edge` repo). #8 showed a bare glibc-slim swap (Ubuntu → Debian) wasn't meaningfully smaller on its own. But barichello/godot-ci's actual weight turned out to be mostly Android SDK/NDK (~2.4GB base, before this repo's own layers) — weight this image never used (no Android export in scope). Dropping that dependency entirely, not just swapping its base OS, is where the real win was. Verified with a real local `docker build` + `docker run`: final image (Godot 4.7.1 + export templates + Blender 4.2.3 + mingw-w64-posix + X11/audio dev libs) = **2343MB total**, vs. barichello/godot-ci:4.7.1's bare base alone = **2460MB** (before any of this repo's packages were added). Godot runs headless, export templates are present, `x86_64-w64-mingw32-gcc-posix` is the active alternative, Blender runs — all smoke-tested in the built image. Implemented on branch `feat/debian-slim-base` (commit 8feeb2b), not yet merged/published. Supersedes the planned use of ticket #3's measurement (that data got captured directly as part of resolving this ticket instead of as a separate session) — closing #3 as redundant.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
wayfinder:grilling
Wayfinder grilling ticket
 wayfinder:map
Wayfinder map issue
 wayfinder:prototype
Wayfinder prototype ticket
 wayfinder:research
Wayfinder research ticket
 wayfinder:task
Wayfinder task ticket
No labels wayfinder:grilling
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
haylan (Arthur Erlich)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: haylan/godot-ci#7