ci: use docker github builder to build bin image

[crazy-max]

similar to moby/moby#51838

Use the Docker GitHub Builder to build the bin image. It now distributes across runners but also generates signed SLSA-compliant provenance attestations.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[docker-agent]

Assessment: 🟢 APPROVE

The migration from the inline bin-image job to a dedicated reusable workflow via docker/github-builder is well-structured. The drafter identified three hypotheses; all three were dismissed after verification:

1. VERSION raw ref — vars: VERSION=${{ github.ref }} passes a raw git ref (e.g. refs/tags/v27.0.0), but scripts/build/.variables explicitly handles all raw ref formats via a case statement (refs/tags/v* → strips to clean semver, refs/heads/* → branch name, refs/pull/* → pr-N). The build scripts were designed for this pattern — not a bug.

2. Unrestricted pull_request trigger — Running the cross-platform build on every PR (vs. the old skip-on-PR behavior) is intentional per the PR description: the Docker GitHub Builder distributes across runners and provides PR-time validation without pushing.

3. id-token: write on PR builds — For fork PRs, GitHub Actions automatically restricts OIDC to none regardless of what the workflow declares. For same-repo PRs, push: false means the reusable workflow should not attempt Docker Hub authentication. The Docker-authored reusable workflow is designed for this pattern.

The SHA-pinned reusable workflow reference (@27ade872c1e2296e62ef15ab3b10d37665e57cf7 # v1.15.0), contents: read global permission, and repository guard (if: github.repository == 'docker/cli') are all good practices correctly carried over.

Dismissed security findings (review manually)

• .github/workflows/bin-image.yml:31 — id-token: write granted on pull_request events (verifier mitigation: fork PRs are protected by GitHub's automatic OIDC restriction; same-repo PRs are protected by push: false in the reusable workflow call)

[docker-agent]

Assessment: 🟢 APPROVE

Dismissed security findings (review manually)

• .github/workflows/bin-image.yml:25 — pull_request trigger combined with id-token: write permission (verifier mitigation: The if: ${{ github.repository == 'docker/cli' }} job guard prevents execution for fork PRs, and GitHub's platform-level controls do not issue OIDC tokens for untrusted pull_request events from forks regardless of the permission declaration. This matches an established pattern in Docker org workflows.)

[crazy-max]

would like to change this cond at some point so we can test build of the bin-image on PRs but needs docker/github-builder#266

[docker-agent]

Assessment: 🟢 APPROVE

The diff replaces the inline multi-step bin-image build with a call to the docker/github-builder reusable workflow. The migration looks functionally correct: the SHA is pinned with a version comment, required permissions (id-token: write) are preserved, OIDC credentials are forwarded via registry-identities, QEMU and cross-compilation targets are carried over, and GHA cache configuration is maintained.

Three low-severity observations were noted but do not warrant blocking this PR:

Lower-confidence findings (not posted inline)

• [low] .github/workflows/build.yml:120 — Dead type=ref,event=pr meta-tag rule — PR events are already excluded by the job-level if: guard (unverified / low)
• [low] .github/workflows/build.yml:102 — Unverified SHA/tag correspondence for docker/github-builder — the # v1.15.0 comment may not match the pinned commit SHA (unverified / low)
• [low] .github/workflows/build.yml:112 — push: true is now hardcoded rather than conditionally gated on github.event_name != 'pull_request'; safe in practice due to the job-level if: guard, but slightly less defensive (unverified / low)

[thaJeztah]

LGTM, thx!