Description

GHA gives us 10GB of cache storage to be leveraged to optimize and speed up things between runs. Bedrock currently doesn't use any of that (besides a few MB npm caches added recently).

Looking into why our build-and-push CI doesn't store any cache blobs (Actions › Caches), consulting https://docs.docker.com/build/ci/github-actions/cache/ sounded like changes to many places, incl. mounts in Dockerfiles etc. — but looking at kitsune, there's nothing too special… besides them building and pushing via action context: https://github.com/mozilla/kitsune/blob/1.6.1/.github/workflows/build-and-push.yml#L115-L122 compared to bedrock shell scripts and trying to pass these to buildkit via buildx setup action config.

So it might be a victim of the bespoke shell–fu, a config context not getting exposed or formatted correctly, not read from a place we expect it to implicitly etc. — or something we do above the basic workflow, which seems to work over at kitsune side (see their caches https://github.com/mozilla/kitsune/actions/caches being stored and the layers used in other runs https://github.com/mozilla/kitsune/actions/runs/20070005886/job/57569092975#step:10:255 only taking seconds…)

Let's see if the buildkit flags we set there are perhaps getting lost in translation somewhere? … an env not passed or something trivial like that.

Alternative would be using "local" cache to the runner, and managing it low level manually via cache action see https://docs.docker.com/build/ci/github-actions/cache/#local-cache

Success Criteria

• Investigate where/why the gha storage max mode is not being applied
• What doesn't need rebuilding over and over could be cached for speeding CI
• Verify the API and storage is not actually slower than just rebuilding fresh all the time