Build claude-code manifest from registry tags directly

[tasuku43]

Summary

• Replace docker pull + docker inspect digest flow in claude-code/Makefile manifest:push with docker buildx imagetools create against the per-arch registry tags directly.
• Switch the idempotency check to docker buildx imagetools inspect so the host's docker daemon state is no longer queried.
• Tolerate hub-tool tag rm failures so a token-scope error does not fail the job after the multi-arch tag is already published.

Why

On the previous PR (#4206), the manifest job failed with Error: No such object: chatwork/claude-code:<version>-aarch64. Root cause: the workflow's manifest job runs on ubuntu-latest (amd64) and does not run docker/setup-qemu-action (only setup-buildx-action). docker pull of a single-arch arm64 image on an amd64 host without QEMU does not create a usable local tag, so the subsequent docker inspect returns "No such object" and the manifest creation fails.

docker buildx imagetools create operates on registry references directly, so it does not depend on the runner's platform support. This sidesteps the missing QEMU setup without changing the shared workflow.

Test plan

• CI manifest job for this PR completes successfully and publishes chatwork/claude-code:<version> and chatwork/claude-code:latest as multi-arch manifests.
• hub-tool tag rm may still fail under the current Docker Hub token scope, but || true keeps the job green; the per-arch suffix tags will linger until the token scope is fixed.

🤖 Generated with Claude Code

[tasuku43]

Local verification

I verified locally that the core change in this manifest:push rewrite — docker buildx imagetools create assembling a multi-arch manifest from registry tag references — works without any local pull. Nothing was pushed (used --dry-run).

1. Per-arch tags exist on Docker Hub

The previous CI run left chatwork/claude-code:2.1.116-aarch64 and :2.1.116-x86_64 on the registry, which I used as inputs.

$ docker buildx imagetools inspect chatwork/claude-code:2.1.116-aarch64
Name:      docker.io/chatwork/claude-code:2.1.116-aarch64
MediaType: application/vnd.oci.image.index.v1+json
Manifests:
  Platform: linux/arm64

$ docker buildx imagetools inspect chatwork/claude-code:2.1.116-x86_64
Name:      docker.io/chatwork/claude-code:2.1.116-x86_64
MediaType: application/vnd.oci.image.index.v1+json
Manifests:
  Platform: linux/amd64

2. Multi-arch manifest assembly (--dry-run)

$ docker buildx imagetools create --dry-run \
    -t chatwork/claude-code:2.1.116 \
    chatwork/claude-code:2.1.116-aarch64 \
    chatwork/claude-code:2.1.116-x86_64

The resulting OCI image index includes both platform manifests:

• linux/arm64 ← digest of 2.1.116-aarch64 (sha256:bf943f...)
• linux/amd64 ← digest of 2.1.116-x86_64 (sha256:d8f14a...)
• Plus 2 build attestation manifests

3. Why this matters vs. the old implementation

The old recipe ran docker pull followed by docker inspect to extract the digest of each per-arch image. On the manifest job's amd64 runner (no QEMU), pulling an arm64 single-arch image does not produce a usable local tag, so docker inspect returned "No such object" and manifest creation failed.

The new recipe passes registry references straight to docker buildx imagetools create, so it does not depend on the host's platform support. The CI workflow's missing setup-qemu-action in the manifest job is sidestepped without touching the shared workflow.

Out of scope

• hub-tool tag rm may still fail under the current Docker Hub token scope. The || true keeps the job green, but the per-arch suffix tags will linger until the token scope is fixed in a follow-up.

[cw-atkhry]

LGTM!