`up`: Compose `build:` service with no Features still builds a label-only stage; put the metadata on the container instead, as for `image:`
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 45/100
- Tipo de issue
- Refactorización
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- docker, docker-compose, typescript
- Área
- build-system, cli
Línea de trabajo
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.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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-L160if (!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_stageplusLABEL devcontainer.metadata=...:
containerFeatures.ts#L199-L217 - A
build:service always carriesimageBuildInfo.dockerfile:
dockerCompose.ts#L167-L184and
imageMetadata.ts,internalGetImageBuildInfoFromDockerfile - The Compose build override with
Dockerfile-with-featuresandBUILDKIT_INLINE_CACHE=1:
dockerCompose.ts#L197-L246(inline cache at L230-L234) docker compose buildruns whenever no container exists yet (noBuild = !!container), passingcanAddLabelsToContainer = true:
dockerCompose.ts#L394-L399and
dockerCompose.ts#L267-L297.
For animage:service with no Features the override has nobuild: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 laterupreads 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.dockerignorenext 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 buildwith animage:service; thisuppath 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.
- Lenguaje dominante
- TypeScript
- Estrellas
- 3k
- Forks
- 466
- Merge medio
- 13 h 28 min
- PR fusionados (30 d)
- 2
Preparar el entorno
Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de devcontainers/cli
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
devcontainers/cli#1325 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 92/100
devcontainers/cli#1203 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 1-3 horas Aptitud para principiantes 68/100
devcontainers/cli#1178 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 Medio día Aptitud para principiantes 45/100
devcontainers/cli#1324 ·
Los mantenedores suelen responder en 1 día
-
`devcontainer build` fails on Buildx 0.37.2 because the generated Dockerfile is outside the Compose bake contextPosiblemente ocupada @v-Kaniska244 la tomó hace 8 días. Abierto
devcontainers/cli#1320 · 1 comentario · 6 reacciones · 1 asignado ·
Los mantenedores suelen responder en 1 día
Todos los issues de devcontainers/cli
Issues similares
-
Bump anybuf version to ^1.0.0Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
wormhole-foundation/wormhole#5062 ·
Los mantenedores suelen responder en 1 día
-
internal os specific
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
frostney/GocciaScript#1688 ·
Los mantenedores suelen responder en 1 día
-
integration:hermes
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
vectorize-io/hindsight#5592 ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
vercel/streamdown#673 · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
apache/rocketmq-dashboard#6712 ·
Los mantenedores suelen responder en 3 días