Add linux/riscv64 to bin-image-cross release target

[gounthar]

- What I did

Added linux/riscv64 to the bin-image-cross target's platform list in docker-bake.hcl, so that official release images include riscv64 binaries.

- How I did it

One-line addition to docker-bake.hcl. linux/riscv64 is already present in the _platforms variable (line 38) and used by the cross, dynbinary-cross, and plugins-cross targets — CI already builds riscv64 binaries. They are simply excluded from the release image because bin-image-cross has its own hardcoded platform list.

- How to verify it

1. Run docker buildx bake bin-image-cross --print and confirm linux/riscv64 appears in the platforms list
2. All other Docker stack components already ship riscv64 release binaries: runc (since v1.1.8), containerd (v2.2.2), BuildKit (v0.28.0), BuildX (v0.32.1), Compose (v5.1.0)
3. I maintain docker-for-riscv64 which has shipped Docker CLI riscv64 binaries across 117+ releases, tested on native hardware (BananaPi F3, SpacemiT K1, rv64gc, Debian Trixie)

- Human readable description for the release notes

- A picture of a cute animal (not mandatory but encouraged)

🐧 (a riscv penguin)

Closes #6857

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[gounthar]

The check-changelog CI job fails with:

PR has a changelog description, but no changelog label

Could a maintainer please add the impact/changelog label to this PR? As a fork contributor, I don't have permission to add labels myself.

The riscv64 builds pass (both static and glibc variants). The other failing job (tests (local, debian, 29)) appears to be a flaky test unrelated to this change; the PR only adds "linux/riscv64" to the bin-image-cross target list in docker-bake.hcl.

[vvoland]

Thanks! LGTM but it still won't make the official packages (hosted at https://download.docker.com/) include the riscv64 binaries.

Our official release pipeline has an explicit list of targets which only includes amd64/arm architectures.
This explicitly does not include arches we don't have native runners for.

[gounthar]

Thanks for the context @vvoland — that makes sense.

Regarding native runners: Cloud-V provides free self-hosted GitHub Actions runners on real riscv64 hardware to open source projects. For example, llama.cpp already uses Cloud-V runners for their native riscv64 CI jobs.

Would Docker be open to exploring that option? If so, I can help with the initial setup and testing. Happy to open a separate issue to discuss adding riscv64 to the release pipeline once native runners are available.

[thaJeztah]

Thanks! Yes, no objection whatsoever to add it in the dockereng/cli-bin image.

As Pawel mentioned; adding it to the download.docker.com package repo, and adding it in the release-pipeline there may be slightly more involved. Native runners could be an option, but we'd have to check (also because parts of the pipeline is private).

We should look though if we can publish images containing the (cross-built) binaries as part or the https://github.com/docker/packaging repository. I thought we also pushed versions for tagged releases there, but at a quick glance, I only see nightly builds; https://hub.docker.com/r/dockereng/packaging/tags?name=cli (I may be mistaken there, but perhaps @vvoland recalls).

[thaJeztah]

LGTM