forked from unom/punktfunk
enricobuehler
6e46734484
flatpak.yml is the last workflow still running a raw distro image and installing
its tools per run. Measured on run 18855, a green 21m23s build whose actual
cargo compile is 6m10s:
63 s dnf -y install nodejs
240 s Tooling — 330 packages
168 s actions/cache restore of ~/.local/share/flatpak (1.5 GB)
i.e. ~7.8 min of setup in front of a 6 min build. Every other heavy workflow
already solved this the same way (rust-ci, fedora-rpm, android-ci, arch-ci...):
a content-keyed image on the LAN registry, rebuilt only when ci/ changes.
The runtimes are the interesting half — a package-only image would leave the
single biggest step in place — and baking them turned out to be free of the
privilege problem it looks like it should have. VERIFIED in a plain `docker run`
container where bwrap was proven broken first ("bwrap: No permissions to
creating new namespace"): `flatpak install --user` still exited 0 and
`flatpak info --user` resolved the ref. flatpak's post-deploy triggers are the
only part that wants bwrap and they are best-effort, so this image needs none of
the --privileged the consuming job needs for flatpak-builder's real sandbox.
The image asserts each ref deployed rather than trusting the install's exit
status: an image that merely LOOKS warm would push 1.5 GB back onto every run,
where it reads as "flatpak got slow again" rather than as a broken image.
Related refs (GL.default{,-extra}, codecs-extra, Locale) are kept deliberately —
they are what --install-deps-only would otherwise pull per run, so a
--no-related image would look smaller and cost more. This moves the same content
the runtime cache already held from the cache server to the registry, where
Docker keeps it on the runner's disk instead of re-extracting it every run.
⚠ The runtime pins now live in two places: ci/flatpak-ci.Dockerfile's ARGs and
the manifest's runtime-version. Drift is not fatal (the prefetch downloads
whatever is missing, retried) but silently costs the win, so bump them together.