Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

`devcontainer build` fails on Buildx 0.37.2 because the generated Dockerfile is outside the Compose bake context

Đang mở
  • Có gì không ổn?
#1,320 0 bình luận 0 reaction 1 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@v-Kaniska244 đang làm issue này rồi.

Từ ngày 7/10/2026.

Đánh giá

Issue này chưa được đánh giá.

Mô tả

@devcontainers/cli 0.89.0 fails devcontainer build for a Compose-based config on Buildx 0.37.2. The build exits in about one second, before any image layer, with:

additional privileges requested: pass "--allow=fs.read=/tmp/devcontainercli-runner/container-features/0.89.0-<id>/Dockerfile-with-features" to grant requested privileges

The same CLI, the same config, and the same generated override succeed on Buildx 0.37.1. That run gets as far as load build definition from Dockerfile-with-features.

Environment

Piece Failing run Succeeding run
@devcontainers/cli 0.89.0 0.89.0
Buildx v0.37.2 (2d379c0c3f22da0d2759d132a0ec81ca949098f0) v0.37.1 (0b265a9f62db554fa9aba6dd19e1bd5704bc7d8a)
Docker Compose v2.38.2 v2.38.2
Docker Engine 28.0.4 28.0.4
Runner image ubuntu24/20261004.327 ubuntu24/20260927.320
Node.js v22.23.3 v22.23.3

Both runs used docker/setup-buildx-action@v4 with the docker-container driver. The driver was not the difference. The repository is private, so the log excerpt below is the part that can be read without that Actions run.

What the CLI ran

devcontainer.json has no features. The Compose service sets image and has no build key. The CLI still printed this override:

services:
  dev:
    image: vsc-<folder-hash>
    build:
      dockerfile: /tmp/devcontainercli-runner/container-features/0.89.0-<id>/Dockerfile-with-features
      context: /tmp/devcontainercli-runner/empty-folder
      args:
        - BUILDKIT_INLINE_CACHE=1
        - _DEV_CONTAINERS_BASE_IMAGE=dev_container_auto_added_stage_label

It then ran:

docker compose --project-name <project>_devcontainer \
  -f <workspace>/.devcontainer/compose.yaml \
  -f /tmp/devcontainercli-runner/docker-compose/docker-compose.devcontainer.build-<id>.yml \
  build <service>

Bake stopped at load local bake definitions. The exception is thrown from dist/spec-node/devContainersSpecCLI.js.

Reduced repro

Buildx v0.37.2 or newer, Compose v2.38.2, and @devcontainers/[email protected].

.devcontainer/devcontainer.json:

{
  "name": "bake-entitlement-repro",
  "dockerComposeFile": "compose.yaml",
  "service": "app",
  "workspaceFolder": "/workspace"
}

.devcontainer/compose.yaml:

services:
  app:
    image: mcr.microsoft.com/devcontainers/base:ubuntu
    command: sleep infinity

npm install -g @devcontainers/[email protected]
docker buildx version
devcontainer build --workspace-folder .

Expected: the build loads Dockerfile-with-features and continues, as it did on Buildx 0.37.1.

Actual on Buildx 0.37.2: exit 1 with additional privileges requested for that Dockerfile.

devcontainer build is the command that hits this with no features configured. In src/spec-node/devContainersSpecCLI.ts it calls buildAndExtendDockerCompose with canAddLabelsToContainer set to false. With no features, getExtendImageBuildInfo still returns featureBuildInfo in that case (src/spec-node/containerFeatures.ts). devcontainer up passes true and, for an image-only service with no features, can attach labels without writing that Dockerfile. up still hits the same override when features are configured, or when the service already has a Dockerfile.

Why Buildx 0.37.2 rejects it

Buildx v0.37.2 changed bake so --progress=rawjson rejects ungranted entitlements instead of skipping the consent check (GHSA-gwr2-q96m-6682). On a non-interactive run, bake returns the additional privileges requested error (bake/entitlements.go).

Compose v2.38.2 always invokes bake as bake --file - --progress rawjson (pkg/compose/build_bake.go). For Buildx 0.17.0 and newer it also passes --allow fs.read=<path>, but only for build.context and additional contexts. It does not pass the Dockerfile directory.

The CLI creates that split in src/spec-node/dockerCompose.ts. It writes Dockerfile-with-features under the features temp folder, then, when the service has no build context, sets context to empty-folder:

const finalDockerfilePath = cliHost.path.join(featureBuildInfo?.dstFolder, 'Dockerfile-with-features');
await cliHost.writeFile(finalDockerfilePath, Buffer.from(finalDockerfileContent));
buildOverrideContent += `      dockerfile: ${finalDockerfilePath}\n`;
// ...
if (!serviceInfo.build?.context) {
    const emptyDir = getEmptyContextFolder(common);
    await cliHost.mkdirp(emptyDir);
    buildOverrideContent += `      context: ${emptyDir}\n`;
}

When the service already has a context, the Dockerfile path is still that absolute features path, outside the context Compose entitles.

docker compose build has no --allow flag, and the CLI does not invoke docker buildx bake itself, so the required fs.read grant is never sent.

Workaround

BUILDX_BAKE_ENTITLEMENTS_FS=0 disables the filesystem check when no other entitlement is missing. That turns the check off for every path, not just this Dockerfile. Pinning Buildx 0.37.1 keeps the rawjson consent skip that 0.37.2 closed.

Suggested fix

Write Dockerfile-with-features inside the context directory Compose already entitles, and reference it with a path under that context. For an image-only service, the features temp folder can be that context, with a relative Dockerfile name. The empty-folder context plus an absolute Dockerfile outside it is the combination Buildx 0.37.2 refuses.

A Compose change that also entitles the Dockerfile directory would help every docker compose build that uses an absolute Dockerfile outside the context. The CLI override is what produces that shape for devcontainer build.

Ngôn ngữ chính
TypeScript
Star
3k
Fork
462
Merge trung bình
13 giờ 28 phút
Pull request đã merge (30 ngày)
2

Chuẩn bị môi trường

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của devcontainers/cli

Tất cả issue của devcontainers/cli

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.