It will immediately push your images so you can’t run build and push in separate hooks unless you do what I did. I used the build hook to build an image with a one tag, then tested every architecture in a loop in the test hook, and I ran docker buildx again with different parameters where I set new tags following semantic versioning.
You can see environment variables in the documentation. You can use those to tag your image based on the build rules you set on Docker Hub, or you can use completey different tags.
Since it is running in one build process, the second build will use the cache and just tag the images quickly.
The first line in my example is necessary to have an emulated build environment for different platforms.
Quick follow up, I appreciate that Docker Hub provides the capability to override the default commands using hooks, and for some people that is probably a great solution.
As I dig in a bit more, though, I find (for myself) that using GitHub workflows / actions to do Multiplatform builds is a win for me, as I have one place that controls the entire CI/CD pipeline (including deployment to my web servers).