devcontainer: pin docker-in-docker to 2.x (fix arm64 prebuild)#92
Conversation
The ":1" pin resolves to a stale frozen 1.x image (the feature has no 1.x releases anymore — it's at 3.x). That old script runs a global `pip install docker-compose` on bookworm/arm64, which fails under PEP 668 (externally-managed-environment) — the arm64 prebuild failure that survived the bookworm pin (#89), the v2-plugin switch (#90), and the dockerDashComposeVersion=none change (#91), because none of them affect which feature version runs. 2.x gates the entire compose/pip block behind `!= none`, so with dockerDashComposeVersion=none there is no pip on arm64 at all. amd64 was unaffected (it gets a prebuilt v1 binary). `docker compose` v2 still comes from the moby-compose package. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Warning Review limit reached
More reviews will be available in 1 hour, 13 minutes, and 49 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more credits in the billing tab to continue. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
1 participant
The actual root cause
The arm64 prebuild kept failing on the same PEP 668
pip installthrough #89, #90, and #91 — because none of those changes affected which version of the docker-in-docker feature runs.ghcr.io/devcontainers/features/docker-in-docker:1resolves to a stale, frozen 1.x image. The feature has no 1.x releases anymore — published tags start at 2.0.1 and the current release is 3.0.1. That old 1.x script runs a globalpip install docker-composeon bookworm/arm64, which fails under PEP 668 (externally-managed-environment). amd64 was never affected — it gets a prebuilt Compose-v1 binary instead of the pip path.I confirmed by reading the released scripts directly: in 2.17.0 and 3.0.1, the entire compose/pip block is gated by
if [ "$DOCKER_DASH_COMPOSE_VERSION" != "none" ]. So:2+dockerDashComposeVersion: none⇒ no pip on arm64 at all.Change
docker-in-docker:1→:2(current 2.x; avoids the abandoned 1.x line).dockerDashComposeVersion: none— the repo only usesdocker composev2 (runtime/docker/compose.go: "legacy docker-compose is not supported"), and the v2 plugin ships via themoby-composeapt package independent of this option.Why I'm confident this time
Earlier fixes addressed real but secondary issues (trixie base, Compose v1 vs v2) without touching the stale version pin, so the same pip step kept running. This removes that step at the source. amd64 already builds green; this should let the multi-arch
:latestmanifest finally publish.Verifiable only by the
DevContainer Prebuildrun onmainafter merge.🤖 Generated with Claude Code