Add "--platform" to GHA generate script

[tianon]

I discovered this was missing when I created a riscv64-only image and it then failed to build on amd64. 😅

It should be totally harmless on most repos since I don't think anyone but me using this script has images that don't support one of either amd64 or windows-amd64, which will automatically be preferred. 🙈

[codecov-commenter]

Codecov Report

Merging #81 (0e6bdaa) into master (ca308fd) will not change coverage.
The diff coverage is n/a.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

@@ Coverage Diff @@## master #81 +/- ##
=======================================
Coverage 73.10% 73.10% =======================================
Files 7 7 Lines 714 714 =======================================
Hits 522 522 Misses 162 162 Partials 30 30 

[tianon]

https://github.com/tianon/dockerfiles/actions/runs/6190609199/job/16807227669 is an example failing job

tianon/dockerfiles@ee0ab6c is where I've swapped in this commit for testing

https://github.com/tianon/dockerfiles/actions/runs/6191900925 is the resulting failing job that's now failing in a more amusing way ("exec format error", because apparently I had erroneously assumed that GHA set up QEMU already by default 😂)

[tianon]

So, I guess for things we can't build natively we can either:

1. skip them entirely; or
2. add "install emulation hooks" code to the prepare section for them

At this point, I think I might be leaning towards the former, but I don't have a problem with doing the latter instead. Thoughts, @yosifkit? (either way, this really doesn't affect anyone I'm aware of except for me, lolsob)

[tianon]

I guess option 3. is "both" and we make it environment-variable-configurable.

[yosifkit]

This is fine as-is and I want #80 to build on top of it.

[tianon]

As is this doesn't actually solve my problem, but that can be a follow-up, I guess. Just need some input on which way to solve it 😅

[yosifkit]

I lean toward skipping as well. But then I feel like the most rational test (checking dpkg --print-architecture) to know what to skip would not allow a user to override it by pre-installing binfmt-support and qemu-user-static. Is there a better test?

Alternatively, I am leaning toward just auto installing binfmt/qemu if the provided arch does not match dpkg. This might initially only be used by your repo, but it could give us opportunity to test some of the official images on alternative arches.

[tianon]

I lean toward skipping as well. But then I feel like the most rational test (checking dpkg --print-architecture) to know what to skip would not allow a user to override it by pre-installing binfmt-support and qemu-user-static. Is there a better test?

That'd be arch-test 👀

• https://manpages.debian.org/bookworm/arch-test/arch-test.1.en.html
• https://github.com/kilobyte/arch-test