Emma Thorpe
45d99ff039
Build and publish container / build (pull_request) Successful in 5m40s
A pull request took roughly eleven minutes to go green, and the log shows one CACHED line in the whole run. The image was being built twice, in full. The test stage is built by the runner's docker daemon. The runtime stage was then built by docker/build-push-action, which runs under a buildx builder that setup-buildx-action creates in its own container with its own cache. The two share nothing, so the second build pulled the base image again, ran pip install again, and exported the layers again -- about four and a half minutes, plus another thirty-five seconds to boot buildkit. The comment above the test step claimed those layers were shared, which is what made this look reasonable. buildx earns that overhead when producing several architectures. This produces linux/amd64 only, by an explicit decision recorded in the workflow, so it earns nothing here. Use plain docker build against the same daemon that ran the tests, and push with docker push. The runtime stage is a strict prefix of the test stage, so every layer is a cache hit: measured at 1.3 seconds locally against roughly four and a half minutes in CI. The remaining time is the runner itself, which is slow in absolute terms -- pytest takes four seconds locally and a hundred and two in CI. That is not something the workflow can fix.