kevinveenbirkenbachandClaude Opus 5.5 5689812fbe perf(sys-svc-compose): build with --pull in the build handlers so they hit pull.py's cache ...

A Dockerfile change notifies compose-up and compose-build in one flush. The compose pull handler (pull.py) builds every buildable service with `compose build --pull`, and the Build compose handler right after it built again with plain `compose build`. BuildKit keys a --pull build and a plain build differently, so the second build missed the first build's cache and ran every RUN layer again; in the stalwart compose roundtrip that was 233 s for tor, 129 s for openldap and 62 s for simpleicons, about 420 s per fresh compose deploy. It also overwrote pull.py's image, built on the freshly resolved base, with one from the plain-build cache: in pass 2 the --pull build of openldap ran its RUN layer again (34.5 s) while the plain build right after it was fully CACHED.

Both build handlers now run `compose build --pull` and fall back to a plain `compose build` when that fails, as pull.py does, so the second build of a flush is a cache hit and a lone-service rebuild keys like the flush builds. Without a reachable registry the fallback builds from the local base exactly as before.

A scratch compose project in the stack's daemon showed the cache behaviour: --pull after --pull CACHED, plain after --pull ran the RUN layer again. The new handler test fails on the old plain `compose build`.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

2026-10-29 15:49:50 +01:00

..

files

perf(sys-svc-compose): build with --pull in the build handlers so they hit pull.py's cache

2026-10-29 15:49:50 +01:00

filter_plugins

feat(sys-svc-compose): decommission the compose stacks of roles no longer active

2026-10-28 03:11:10 +01:00

library

test: settle the CodeQL notes on the unit test imports

2026-10-28 03:29:23 +01:00

lookup_plugins

refactor(python): clear the open CodeQL code-quality alerts

2026-10-20 21:40:58 +02:00

__init__.py

…