kevinveenbirkenbach
230d9a1e5e
The package cache was configured in six places at once: the nginx upstream map, the consumer compose override, pip.conf, .npmrc, the apt sources and the twenty ensure_proxy_repo calls that bootstrap Nexus each spelled the same hostnames, repository names and suites by hand. A new upstream meant editing five files and hoping none was missed, and the docs told contributors to do exactly that. A role now declares what it needs under cache: in its meta/networks.yml, and everything else is derived from it. svc-cache-package holds the general upstreams; web-svc-libretranslate holds its own. All nine derived files are generated and gitignored, so a second spelling of a hostname cannot exist. utils.cache.hosts reads the declarations without PyYAML, because the .env generator reaches them before any dependency is installed; it raises rather than truncate when a comment sits at column 0 inside the block, which would otherwise drop every declaration below it in silence. utils.cache.records owns the Nexus record format and the Ubuntu mirror resolution, so the dev stack and the role provision from one rendering. A build may only resolve a cached host it can verify: the plain-HTTP hosts are hijacked for every image, and the TLS hosts only for an image whose Dockerfile installs the frontend CA. Hijacking all of them would fail every pip and npm build with CERTIFICATE_VERIFY_FAILED. svc-cache-package deploys the cache and its TLS frontend by calling the same shell scripts the dev stack calls, rather than reimplementing them as tasks. The role is invokable through the new svc-cache category and inert until a host carries it. Verified: the twenty Nexus payloads, the fifteen nginx server blocks and all seven package-manager configs are byte-identical to the hand-written files they replace, and the new category adds one role to the deploy order while preserving the relative order of the other 180. The role has not been deployed yet.
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
infinitocontainer, either as the container entrypoint, as a DockerHEALTHCHECK, or as asystemdunit 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.