inner
inner
¶
Generate the scripts that run inside a slot's test container.
Two scripts per slot, both written to the shared results mount so the
container executes real files — the historical bash -c string with
its three levels of quote-escaping is gone:
- the outer script runs as root: copy the read-only source mount into a writable workspace, prove the init system matches the slot's contract, then drop to the slot's test user;
- the inner script runs as the test user: export the capability contract, bootstrap a Python 3.12 venv plus uv, sync the repo's locked dependency groups, and walk the configured phases.
A slot that boots systemd under krun also gets the units its systemd runs
the outer script through (boot_units).
Command phases abort the slot on failure (set -e); pytest phases
record the first failing exit code and keep going, so a single run
surfaces every failing suite.
TEST_UID = 1000
module-attribute
¶
BOOT_TIMEOUT_SECONDS = 300
module-attribute
¶
MASKED_UNITS = ('systemd-firstboot.service', 'console-getty.service')
module-attribute
¶
outer_script(config, slot_name, *, boots_systemd=False)
¶
Root-side container entry: workspace prep, init-system proof, user drop.
boots_systemd is the runner's call: the slot may boot systemd, and its
image ships it. There this script is the slot service's ExecStart
(see boot_units), not the
container command; the flow is otherwise the same.
Source code in src/terok_util/matrix/inner.py
inner_script(config, slot_name, scope='all')
¶
Test-user-side flow: env contract, venv + deps, configured phases.
Source code in src/terok_util/matrix/inner.py
boot_units(slot_name)
¶
The units a booted slot runs through, keyed by path under the control dir.
crun's krun handler implements no exec, so nothing reaches a booted
microVM through podman exec. Its systemd starts terok-matrix.target
instead: the normal boot, then the outer script as a oneshot service.
The service pipes the script's output to the console, which libkrun
hands to podman's stdout as log records; the runner strips their prefix.
Nothing reopens
libkrun's krun-stdout port: systemd closed it on taking over PID 1,
and libkrun panics when a port opens a second time. The service
records its exit status on the results mount, because podman's own
status is the VM's, and then ends the VM with a reboot, the way
libkrun's own init ends it. A boot that does not reach
multi-user.target in time ends the VM the same way.