Ranked recommendation: fix the docker system prune -af --volumes step
first (it deletes BuildKit's build cache before every build, so no
Dockerfile change can help until that stops), then split the
apt-get install layer from the Godot/Blender download layer so the
~470s apt layer becomes cache-eligible across nightly runs. Registry
cache and Gitea Actions' actions/cache don't fit this repo's single
persistent runner / multi-GB nightly-changing layers.
Research only, no code changes.
Godot's headless --import/--export-release refuses to auto-detect Blender
for .blend import: "Blender path is invalid or not set... Cannot configure
blender path in headless mode" (modules/gltf/editor/editor_scene_importer_blend.cpp).
Without this, the image's Blender install was silently unusable for its one
job — no .blend file would ever import in CI.
Bakes filesystem/import/blender/blender_path into a per-minor-version
EditorSettings .tres, same pattern barichello/godot-ci and abarichello's own
Dockerfile use for Android SDK/JDK paths.
Found and verified while resolving ticket #9 (Merge, publish, and validate
the debian-slim image end-to-end): confirmed a .blend import produces a real
.scn with this fix, and fails without it, on a real container built from
this Dockerfile.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
docs/handoff/godot-ci-custom-image.md was the original handoff spec for this
repo's creation, already marked "done, and superseded" — it describes the
barichello/godot-ci-based Dockerfile this repo has since moved off of (see
wayfinder map #2, ticket #7). No longer a useful reference now that the
current README and Dockerfile are the source of truth.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Drop the dependency on barichello/godot-ci as a base image (Ubuntu, ~2.4GB
before this repo adds anything, most of it Android SDK/NDK weight this image
never uses). Download Godot's editor and export templates directly from its
official godot-builds releases instead, the same source barichello's own
Dockerfile pulls from.
Alpine was the first candidate considered and rejected: official Godot and
Blender binaries are glibc-only, and Alpine's musl-native alternatives for
both live only on its unpinned edge repo (see wayfinder tickets #4, #5, #6).
A glibc-slim distro turned out not to be meaningfully smaller than Ubuntu
either (#8) — but dropping barichello's Android-SDK-laden base entirely
still nets a real win: local build measured 2343MB total (Godot + export
templates + Blender + mingw-w64 + X11 dev libs) vs. barichello's bare base
alone at 2460MB before this repo's layers were ever added.
publish.yml's barichello-tag gate is replaced with a check against the
godot-builds release we now actually depend on.
Decided via wayfinder map #2, ticket #7:
#7
Answers wayfinder ticket #8: does a glibc-based slim distro
(debian:bookworm-slim / trixie-slim) get most of Alpine's size win
without the musl risk #4-#6 found?
Verdict: not worth it. Debian bookworm-slim (26.92 MB compressed) is
within ~5% of ubuntu:noble (28.37 MB) per Docker Hub's official image
listings - nowhere near Alpine's musl size class. Debian does clear
every capability gap Alpine hit (posix-threads mingw-w64 in stable,
X11/audio dev headers, official Blender tarball runs unmodified since
it's glibc), but the size case for leaving Ubuntu was Alpine's alone.
Related to #4, #5, #6
Answers wayfinder issue #6: Alpine's community/edge repo ships a
posix-threads-only mingw-w64-gcc cross toolchain, but it's edge-only
(not in a stable release) and no primary source confirms anyone has
built Godot Windows export templates with it.
Related to #6
Captures findings for wayfinder ticket #4: whether official Godot
Linux editor/export-template binaries run under Alpine/musl.
Throwaway research branch, not intended to merge.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Verdict: official glibc tarball does not run on Alpine as-is; gcompat
is not a credible fix for something Blender-sized (per gcompat's own
docs and one concrete failed community attempt). A musl-native
alternative exists (Alpine community's blender-headless package,
5.2.0-r0) but only on the edge branch, not a stable release — a real
argument against Alpine for this pipeline's pinned-version needs.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
scripts/resolve-blender-url.sh, resolve-godot-version.sh, and
test-lib.sh were committed as mode 644 (Windows checkouts don't
preserve the git exec bit, and it was never set). publish.yml invokes
the first two as ./scripts/resolve-*.sh, which needs it — the runner
failed with "Permission denied". lib.sh stays 644, it's only sourced.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Auto-tracking the newest Godot/Blender means most nightly runs now
build genuinely new multi-GB layers instead of hitting cache, and
nothing ever pruned old ones — the runner's disk fills up over
successive runs until a push fails. Prune before building, and retry
docker push a few times to ride out transient registry 500s.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
blender --version failed with "libxkbcommon.so.0: cannot open shared
object file" — libxkbcommon0, libsm6, and libice6 aren't pulled in by
anything else in the image. Caught via a local docker build (see
README), which the prior push-only workflow never exercised.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Replace the fixed 4.7.1 Dockerfile/workflow pin with:
- a nightly schedule that resolves the newest stable Godot (4.0+) and
newest stable Blender, and builds+pushes <version> plus a floating
latest tag only when the Godot version actually changed
- a workflow_dispatch free-text version input to (re)build any specific
Godot version on demand, always with newest-at-build-time Blender,
overwriting that tag without touching latest
- scripts/resolve-godot-version.sh and scripts/resolve-blender-url.sh,
with shared parsing logic in scripts/lib.sh and an offline smoke test
in scripts/test-lib.sh
- Blender is now fetched directly from download.blender.org instead of
apt (Ubuntu noble's apt package is stuck on 4.0.2)
- drop the push-to-main trigger; schedule + workflow_dispatch only
Scope is Godot 4.0+ only — .blend import is a Godot 4 feature, so 3.x
builds have no use for the Blender toolchain this image adds.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Gitea packages belong to the owner, not a repo, by default — pushing
alone doesn't surface the image under this repo's Packages tab, and
the org.opencontainers.image.source label some workflows set for this
doesn't auto-link on Gitea (closed feature request, never
implemented). Call the link API explicitly after push instead.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Bakes export-template.yml's apt-get toolchain into an image extending
barichello/godot-ci:4.7.1, plus a publish workflow to push it to this
repo's Gitea package registry.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
haylan
