Files
computer-playbook/scripts/docker
kevinveenbirkenbachandClaude Opus 4.7 b278cd8ccd refactor(entry.sh): switch INFINITO_COMPILE{,_SILENCE} env-vars to flags
scripts/docker/entry.sh's two compile-control reads (INFINITO_COMPILE
and INFINITO_COMPILE_SILENCE) crashed during Dockerfile RUN because
that context has no env-pipeline: env/default.env exists in the repo
but no make/BASH_ENV/load.sh chain materialises it into the running
shell. The bare reads under `set -u` triggered unbound-variable exit
even though the keys were registered in default.env + passthrough.

Move build/silence control from env to script flags so entry.sh is
self-contained at bootstrap time. Each flag now triggers its action
directly inside the parse loop -- no COMPILE/SILENCE state vars:

    --compile         -> run_local_build (streaming)
    --compile-silent  -> run_local_build >/dev/null 2>&1
    --                -> end flag parsing, rest is the exec target

Drop INFINITO_COMPILE + INFINITO_COMPILE_SILENCE from the whole
registry surface: env/default.env, passthrough.STATIC_KEYS, the
infinito_compile handler (gone entirely), compose.yml's env
injection block, the dotenv-generator baseline test, the
build_env unit-test fixture, and the now-no-op `-e INFINITO_COMPILE=0`
in test-install-{make,pkgmgr} workflows.

Dockerfile RUN switches to `entry.sh --compile -- true`; runtime
ENTRYPOINT receives no flags so the default (no-compile) holds and
exec hands off to systemd via the CMD.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-20 23:25:39 +02:00
..
…

Docker Runner Scripts 🐳

Shell helpers that run inside the infinito runner container defined by the top-level compose.yml. They cover container lifecycle (entry, healthcheck) and integration with peer compose services (e.g. the registry-cache pull-through proxy).

Scope 📋

  • This directory MUST contain only scripts that execute inside the infinito container, either as the container entrypoint, as a Docker HEALTHCHECK, or as a systemd unit hook.
  • This directory MUST NOT host host-side tooling. Scripts that run on the developer or CI host belong under their workflow-specific path (for example scripts/tests/, scripts/image/, scripts/meta/).
  • This directory MUST NOT host application logic that belongs to an Ansible role.

Bind-mounted scripts 🔗

A script that is bind-mounted from this directory into a fixed in-container path (see compose.yml) MUST keep its git executable bit, because Docker bind-mounts preserve host file permissions and the in-container caller (systemd, dockerd, the entrypoint) cannot recover from a non-executable mount.

When a new script is added with a bind-mount target, its purpose and in-container target path SHOULD be documented at the call site (the matching compose/<service>/ README, or compose.yml.md).

Distro portability 🌐

A script in this directory MUST work across every distro variant that the runner image is built for (currently Debian, Ubuntu, Arch, Fedora, CentOS). Tool availability differs across these variants, so a script SHOULD branch on command -v <tool> rather than on distro IDs.