ci(docker): cache buildx layers between master builds

[andy5995]

No description provided.

[NuSkooler]

Good idea and the master-only reasoning holds. A couple of things to weigh first, inline.

[NuSkooler]

The reasoning here is right -- this workflow is push: [master] plus workflow_dispatch, so the cache really is only ever written by master, and the QEMU arm legs are exactly the part worth caching.

Two things before it goes in.

mode=max shares a 10 GB budget with the workflows that gate every PR. It caches every intermediate layer across three platforms, native rebuilds included, which adds up quickly. That storage is the repo-wide GitHub Actions cache, and test.yml and lint.yml both use actions/setup-node with cache: npm, as do the two website workflows. Eviction is LRU across the whole repo, so a large Docker cache can quietly evict the npm caches that keep PR checks fast -- trading a slow master build for slow checks on every pull request.

I would start at mode=min and see what the arm legs actually save before reaching for max.

The actions underneath this are old. The workflow pairs setup-qemu-action@v3 and setup-buildx-action@v3 with build-push-action@v3 (2022) and login-action@v2. Which cache protocol type=gha ends up speaking depends on the buildx/BuildKit version behind it, so bumping build-push-action belongs in this PR rather than layering a cache config onto an old action.

And one that is not really yours to fix here: this workflow has no pull_request trigger, so nothing in this PR is exercised before merge -- the first real run is on master, in the job that publishes :latest. Worth a manual workflow_dispatch run off this branch to confirm the cache engages at all. A separate PR adding a pull_request trigger that builds without pushing would give Docker changes the same safety net the rest of the tree already has.

[NuSkooler]

Heads up before you spend more time on this: I have a change for #811 ready that adds a pull_request trigger to this workflow, building all three platforms with push: false behind a paths filter. It lands on the same lines you're touching, so this will want a rebase — the push: true you append after becomes push: ${{ github.event_name != 'pull_request' }}.

It also undercuts the comment here. "Nothing here runs on a pull request, so the cache is only ever written by master" stops being true, and that matters more than the wording: with cache-to unconditional, every Docker-touching pull request would write its own branch-scoped cache into the same repo-wide 10 GB. Branch caches can read from master's but not the other way round, so those writes buy nothing and evict things that do — including the cache: npm entries test.yml and lint.yml rely on for every PR.

So once #811 is in, this probably wants:

cache-from: type=gha
cache-to: ${{ github.event_name != 'pull_request' && 'type=gha,mode=max' || '' }}

which lets a pull request warm off master's cache without writing one back. That also makes mode=max easier to live with, since master is then the only writer — though I'd still start at mode=min and see what the arm legs actually save before reaching for max.

Happy either way on sequencing: I can hold #811 until this lands and rebase mine instead, if you'd rather not redo yours.