up: probe the Docker daemon architecture instead of assuming the host GOARCH for the devcontainer platform key

pti commented

2026-10-19 23:08:19 +02:00

Owner

Tracks the TODO at cmd/up.go resolveDevcontainerPoolPlan, design/harness/unified-harness-pool.md section 5.1. The devcontainer runtime derives the target platform key from pool.HostPlatformKey, this host's GOARCH, as a stand-in for the Docker daemon's default platform. That is right for every local Docker Desktop or Engine setup but wrong for a remote DOCKER_HOST whose daemon architecture differs from the client, where up would look for the wrong active pointer and mount or verify the wrong runtime tree. Proposal: ask the daemon once, for example docker version with a Server.Arch format, map the answer onto the pool platform key enum, fall back to the host key with a notice when the probe fails, and cover the mapping with a table test. Also applies to wraptool init devcontainer where it prints the mount snippet with a concrete platform path. Found via the three accepted Sonar S1135 TODO findings in cmd/up.go.

pti referenced this issue from a commit

2026-10-19 23:40:58 +02:00

fix(up): take the devcontainer platform key from the Docker daemon's architecture

pti referenced this issue from a pull request that will close it,

2026-10-19 23:41:21 +02:00

fix/up: take the devcontainer platform key from the Docker daemon's architecture #106

pti closed this issue

2026-10-19 23:44:11 +02:00

Rows
Columns

up: probe the Docker daemon architecture instead of assuming the host GOARCH for the devcontainer platform key #103