I while back I built a number of pipelines using the docker-build-push action here. This uses buildx and buildkit to do its build/push stuff, and allows if needed for things like multi-arch builds. However what I quickly discovered was that you could not use ECR for the caching part of this, which at the time was very annoying. I built a custom S3 backed registry for caching only, but it looks like now you can use ECR natively for this caching now:
BuildKit has recently released version 0.12, which includes a contribution by Amazon ECR engineering for a solution that allows for a remote build cache to be generated and stored in an OCI-compatible way. This means that BuildKit stores and retrieves the build cache in registries that implement the OCI specification, like Amazon ECR. With this update, you can push a cache image to an Amazon ECR repository separately from the built and pushed image. This cache image can then be referenced in future builds to provide significant speedups to your time-to-push, whether you’re just pushing from your laptop or from your production CI/CD builds on platforms like GitLab or GitHub Actions.
https://aws.amazon.com/blogs/containers/announcing-remote-cache-support-in-amazon-ecr-for-buildkit-clients/
The magic here at least for the github action is the setup for the buildx which is done here. The action will install the latest version of the buildkit by default, though if you are doing this outside of github actions of course you will need to ensure that you are using buildkit >= 0.12.
So in your buildkit script or action you can now use (assuming ECR here instead of example.com):
cache-from: type=registry,ref=<aws account id>.dkr.ecr.<region>.amazonaws.com/<repo name>:cache
cache-to: type=registry,image-manifest=true,oci-mediatypes=true,ref=<aws account id>.dkr.ecr.<region>.amazonaws.com/<repo name>:cache,mode=maxYou may also need to set provenance: false here if using the image for a lambda as there is still some issue with the image provenance information in that use case.