`up`: Compose `build:` service with no Features still builds a label-only stage; put the metadata on the container instead, as for `image:`

Đang mở

#1,327 mở ngày 13/10/2026 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

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

Chưa có ai nhận issue này.

Đánh giá

Độ khó: 3/5
Thời gian dự kiến: 1-2 ngày
Mức phù hợp với người mới: 45/100

Loại issue: Tái cấu trúc
Độ rõ ràng: Khá rõ ràng
Mức độ hoạt động: Sôi nổi
Công nghệ: docker, docker-compose, typescript
Lĩnh vực: build-system, cli

Hướng nghiên cứu

The condition canAddLabelsToContainer && !imageBuildInfo.dockerfile in src/spec-node/containerFeatures.ts (around line 153) decides whether the label stage is generated. Check how buildAndExtendDockerCompose in src/spec-node/dockerCompose.ts writes the build override. Done when up on a Compose build: service with no Features puts the metadata label on the container and runs a plain docker compose build, and devcontainer build behaves as before.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Identity: TBaltensperger @ nuitio/devcontainer

This comes from nuitio/devcontainer, a private repository that ships a dev-container template on the Compose build: route; the measurements below are from its CI runners.

What happens

With a Docker Compose config whose service uses build: (a Dockerfile) and a devcontainer.json that declares no Features, devcontainer up creating a new container does not run the service's Dockerfile as written. It writes a copy, Dockerfile-with-features, to a temp folder with one more stage that only adds the devcontainer.metadata label, and builds that copy with BUILDKIT_INLINE_CACHE=1.

For an image: service with no Features the CLI skips that stage and puts the metadata on the container as a label (#267). The build: route is left out of that only because of the !imageBuildInfo.dockerfile condition.

Code at v0.89.0 (the latest on npm; these files are unchanged on main at 155f8b2):

No Features: labels go on the container only when there is no Dockerfile; otherwise the label stage is built.
containerFeatures.ts#L152-L160

if (!featuresConfig) {
    if (canAddLabelsToContainer && !imageBuildInfo.dockerfile) {
        return { labels: { [imageMetadataLabel]: JSON.stringify(getDevcontainerMetadata(...).raw) } };
    }
    return { featureBuildInfo: await getImageBuildOptions(params, config, dstFolder, baseName, imageBuildInfo) };
}

The label stage itself, FROM $_DEV_CONTAINERS_BASE_IMAGE AS dev_containers_target_stage plus LABEL devcontainer.metadata=...:
containerFeatures.ts#L199-L217
A build: service always carries imageBuildInfo.dockerfile:
dockerCompose.ts#L167-L184 and
imageMetadata.ts, internalGetImageBuildInfoFromDockerfile
The Compose build override with Dockerfile-with-features and BUILDKIT_INLINE_CACHE=1:
dockerCompose.ts#L197-L246 (inline cache at L230-L234)
docker compose build runs whenever no container exists yet (noBuild = !!container), passing canAddLabelsToContainer = true:
dockerCompose.ts#L394-L399 and
dockerCompose.ts#L267-L297.
For an image: service with no Features the override has no build: section, so this build does nothing.
The labels-on-the-container path already exists for Compose: the labels go into the start override's labels:
(dockerCompose.ts#L411-L412,
#L565-L567), and a later up reads the metadata from the container's labels
(imageMetadata.ts#L441-L445).

Measurement

Dev Containers CLI 0.89.0, Docker 29.8.2, 12-CPU Linux runner. Each figure is the median of three devcontainer up runs that create a new container, timed from --log-level trace. No Features in either config, and every layer of the Dockerfile is cached.

Compose service	`up` total	build step
`image:`	12.7 s	0.4 s (nothing to build)
`build:` (Dockerfile)	14.5 s	3.3 s (range 2.6–4.0 s)

Each new container on the Dockerfile route spends about 3 s more in the build step. Part of that is the cached rebuild of the service's own Dockerfile, which still has to run so that changes to it are picked up. The rest is the generated Dockerfile, the extra stage and the inline-cache export.

Why `build:` was left out, as far as I can tell

In #267, @chrmarti explained the split: LABEL allows larger values than --label (about 1.3 MB against 0.5 MB in testing), so --label is used "when adding metadata is the only reason for using an additional (or modified) Dockerfile". With a Dockerfile there is a build anyway, so the stage looked free. devcontainer build passes canAddLabelsToContainer = false and still bakes the label into the image, which is right.

Nothing in up needs the label on the image: a later up reads it from the container, and the image: route already depends on that. The metadata for a config with no Features is the same size on both routes, so the image: route already accepts the --label size limit.

The stage is not free either. Besides the time, building a generated copy of the Dockerfile from a temp folder causes trouble of its own:

#969: a Dockerfile.dockerignore next to the original Dockerfile is ignored.
#1320: Buildx 0.37.2 bake refuses a Dockerfile that is outside the build context. That report is for devcontainer build with an image: service; this up path generates the same kind of override.

Request

On up, for a Compose build: service with no Features, put the metadata on the container as a label, as for an image: service, and build the service as written with a plain docker compose build, with no generated Dockerfile, no extra stage and no extra build args.

The smallest change I can see: drop && !imageBuildInfo.dockerfile from the condition in containerFeatures.ts#L153. devcontainer build stays as it is, because it passes canAddLabelsToContainer = false. Then buildAndExtendDockerCompose writes no build override for the service, and the existing docker compose build builds the user's Dockerfile unchanged. The single-container Dockerfile route passes false explicitly in singleContainer.ts#L150 and could get the same treatment from up.

If the label size limit is the concern, one option is to keep the stage only when the serialized metadata is close to the --label limit.

Ngôn ngữ chính: TypeScript
Star: 3k
Fork: 466
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.

Không có Dockerfile hay tệp Docker Compose
Không có mẫu pull request
Đọc hướng dẫn đóng góp

Bắt đầu từ đâu

Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
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.
Fork repository và làm thay đổi trên một nhánh.
Mở pull request có tham chiếu số hiệu của issue.

Issue khác của devcontainers/cli

features generate-docs: `$` sequences in NOTES.md and descriptions are expanded as String.replace patterns, splicing the README template into the output
Đang mở
- Có gì không ổn?
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100

devcontainers/cli#1325 · Mở ngày 8/10/2026

Maintainer thường phản hồi trong vòng 1 ngày
README npm install section mentions Python and C/C++ but they are no longer needed
Đang mở
- Có gì không ổn?
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 92/100

devcontainers/cli#1203 · Mở ngày 14/4/2026

Maintainer thường phản hồi trong vòng 1 ngày
test: findUserArg has no unit tests
Đang mở
- Có gì không ổn?
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 68/100

devcontainers/cli#1178 · 1 bình luận · Mở ngày 18/3/2026

Maintainer thường phản hồi trong vòng 1 ngày
Feature option values are changed before install.sh sees them: quotes are stripped, and `$…` is expanded or executed
Đang mở
- Có gì không ổn?
Độ khó 3/5 Nửa ngày Mức phù hợp với người mới 45/100

devcontainers/cli#1324 · Mở ngày 8/10/2026

Maintainer thường phản hồi trong vòng 1 ngày
`devcontainer build` fails on Buildx 0.37.2 because the generated Dockerfile is outside the Compose bake context
Có thể đã có người làm @v-Kaniska244 đã nhận 7 ngày trước. Đang mở
- Có gì không ổn?
devcontainers/cli#1320 · 1 bình luận · 6 reaction · 1 người được giao · Mở ngày 6/10/2026

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

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

Issue tương tự

`mode="static"` parses the whole document twice on mount (since the caret host in 2.7)
Đang mở
- Có gì không ổn?
bug

Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100

vercel/streamdown#673 · 1 reaction · Mở ngày 15/10/2026

Maintainer thường phản hồi trong vòng 1 ngày
docs(stream-protocol): document messageMetatadata on start/finish and the message-metadata chunk
Đang mở
- Có gì không ổn?
factory-active task-identify-harness-labels-done task-identify-issue-type-done

Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100

vercel/ai#23375 · 1 bình luận · Mở ngày 15/10/2026

Maintainer thường phản hồi trong vòng 1 ngày
Align existing-version-tag example with semantic table
Đang mở
- Có gì không ổn?
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100

agilepathway/label-checker#721 · Mở ngày 15/10/2026

Maintainer thường phản hồi trong vòng 1 ngày
E2BIG in getVisitedCommitDetails on large repositories (since v18.5.0)
Đang mở
- Có gì không ổn?
CLI Empathy needs triage

Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100

chromaui/chromatic-cli#1524 · Mở ngày 15/10/2026

Maintainer thường phản hồi trong vòng 1 ngày
Client: mobile layout's server kebab Disconnect/Reconnect can do the opposite of its label
Đang mở
- Có gì không ổn?
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100

amiantos/lurker#1136 · Mở ngày 15/10/2026

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

Thêm issue về TypeScript

`up`: Compose `build:` service with no Features still builds a label-only stage; put the metadata on the container instead, as for `image:`

Có gì không ổn?

Đánh giá

Hướng nghiên cứu

Mô tả

What happens

Measurement

Why build: was left out, as far as I can tell

Request

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

Bắt đầu từ đâu

Issue khác của devcontainers/cli

Có gì không ổn?

Có gì không ổn?

Có gì không ổn?

Có gì không ổn?

Có gì không ổn?

Issue tương tự

Có gì không ổn?

Có gì không ổn?

Có gì không ổn?

Có gì không ổn?

Có gì không ổn?

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

Why `build:` was left out, as far as I can tell