c8d: inconsistent presentation of ARM64 images (linux/arm64 vs linux/arm64/v8)
まだ誰も着手していません。
評価
調査の方向性
docker image ls --tree のエントリポイントから始め、表示するプラットフォーム名がどのように選択されるかを追跡してください。issue ではファイルもテストも指定されておらず、正規化、API の動作、将来の ARM64 バリアントが未解決のままです。実装と検証の前に、望ましい表現について決定する必要があります。
索引モデルが issue の本文から書いたものです。
説明
Description
From https://github.com/moby/moby/issues/48604 by @thaJeztah
Description
I noticed that there's some inconsistency in presentation of arm64 platforms; one of my images was built with linux/arm64 (no variant), and it looks like we present this as-is.
docker image ls --tree
WARNING: This is an experimental feature. The output may change and shouldn't be depended on.
IMAGE ID DISK USAGE CONTENT SIZE USED
alpine:latest beefdbd8a1da 13.6MB 4.09MB
├─ linux/arm64/v8 9cee2b382fe2 13.6MB 4.09MB
├─ linux/amd64 33735bd63cf8 0B 0B
├─ linux/arm/v6 50f635c8b04d 0B 0B
├─ linux/arm/v7 f2f82d424957 0B 0B
├─ linux/386 b3e87f642f5c 0B 0B
├─ linux/ppc64le c7a6800e3dc5 0B 0B
├─ linux/riscv64 80cde017a105 0B 0B
└─ linux/s390x 2b5b26e09ca2 0B 0B
thajeztah/ddshell:latest e332ae952d63 23.8MB 7.88MB ✔
├─ linux/arm64 1b9c0c672878 23.8MB 7.88MB ✔
└─ linux/amd64 65b8d31def37 0B 0B
AFAIK, linux/arm64 is always equivalent to linux/arm64/v8
docker pull --platform=linux/arm64 thajeztah/ddshell:latest
latest: Pulling from thajeztah/ddshell
8f5adf85e8b9: Download complete
9b3977197b4f: Download complete
414aa140181c: Download complete
b8a650d25df2: Download complete
Digest: sha256:e332ae952d6326b017e64cbb66f2514906e8d9cad56dc5d554e7cd6474f1cd45
Status: Downloaded newer image for thajeztah/ddshell:latest
docker.io/thajeztah/ddshell:latest
docker pull --platform=linux/arm64/v8 thajeztah/ddshell:latest
latest: Pulling from thajeztah/ddshell
Digest: sha256:e332ae952d6326b017e64cbb66f2514906e8d9cad56dc5d554e7cd6474f1cd45
Status: Image is up to date for thajeztah/ddshell:latest
docker.io/thajeztah/ddshell:latest
I wonder if
- we should present it in its canonical / fully-qualified format, or if we should continue presenting as-is
- ❓ would there ever be ambiguity once a
v9becomes available (and in that case, wouldlinux/arm64be equal tolinux/arm64/v9?) - ❓ if we do want to present in canonical form, should we consider that presentation (i.e., handle this on the CLI side), or should this be done on the API side (API doing normalizing)?
- 主要言語
- Go
- スター
- 6.1k
- フォーク
- 2.2k
- 平均マージ
- 1日 10時間
- マージ済み PR(30日)
- 47
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
docker/cli のほかの issue
-
kind/bug status/0-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
-
kind/bug status/0-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
-
kind/feature status/0-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
-
kind/bug status/0-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
似ている issue
-
難易度 1/5 1時間未満 初心者へのやさしさ 60/100
github/gh-aw-mcpg#13748 ·
-
agentic-workflows
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
-
needs-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
googleapis/librarian#7670 · コメント 2 件 ·