[joelwurtz]

0.9.0 backed every registry cache with a GitHub Actions one on CI, to make up for the registry cache missing layers at random (jolicode/docker-starter#430). That miss is a BuildKit race instead (moby/buildkit#6418), detailed in jolicode/docker-starter#448:

• services built together in one bake session, which share a stage (an application and its builder sharing php-base), each import a cache describing that stage. BuildKit keeps one of them and randomly rebuilds the steps of the other services;
• a second cache on the same target races the same way, so the GitHub Actions cache made it worse;
• the docker driver of the runners also failed every build exporting it (Cache export is not supported for the docker driver).

Changes

• Removed the automatic GitHub Actions cache: a service only gets the registry cache of withRegistryCache(), as before 0.9.0, plus whatever is given to its cacheFrom().
• Added docker:build --parallel and the build_parallel context variable: each service builds in its own session, all of them in parallel, and its log is printed once it is done. docker:up --build and docker:push follow them, --no-parallel turns it off for one command.

Measured

On jolicode/redirection.io CI (11 services, the builder stage was rebuilt on almost every run and on every cache push):

	Build infrastructure	builder stage
one docker compose build	83s	rebuilt
one build per service, registry + GitHub Actions cache	119s	rebuilt
one build per service, registry cache only	53s	cached