Closed max06 closed 1 year ago
Side node: Your issue reporter is lying - there was no preview to edit, issue went public immediately. Bad if you want to remove sensitive details.
Issue reporter wording is tracked in https://github.com/microsoft/vscode/issues/115157. Thanks.
Could you append the full log after this failed? (F1
> Dev Containers: Show Container Log
)
Hey @chrmarti
there you go - some details were removed.
Short info about the structure:
/home/vscode
is a named volume, /home/vscode/.vscode-server
is a temporary volume destroyed on rebuild. Build step 11 ensures proper ownership.Could you also append /tmp/devcontainercli-root/container-features/0.19.0-1665396468382/Dockerfile-with-features
? I see the target being passed in with --build-arg _DEV_CONTAINERS_BASE_IMAGE=dev
.
Not sure if that's the correct file - I only found one at /tmp/build-features/Dockerfile-with-features
inside the container. Passing you its content below.
I have the same problem with v0.255.2
when starting the dev container all stages are built. My configuration file looks like this:
{
"name": "application",
"dockerFile": "../Dockerfile",
"build": {
"target": "devel"
},
"context": "..",
"remoteUser": "devel",
"runArgs": [
"--volume=${localWorkspaceFolder}:/workspace:z",
"-e=IMAGE_DEBUG=false"
],
"workspaceFolder": "/workspace"
}
@joda01 why does your config look so different to mine? At least dockerFile
and context
are inside of build
for me...
@max06 I tookk this from an official Microsoft example, but you're right the reference tells us to do different:
There is a gap somewhere in the documentation. The plugin tells me to put the dockerFile
key on top, the documentation tells to put it into build.dockerFile
.
Okay; seems to be legacy stuff: On top it is called dockerFile
in build it is called build.dockerfile
(upper lower case difference) corrected it, but same behaviour
{
"name": "application",
"build": {
"dockerfile": "../Dockerfile",
"target": "devel",
"context": ".."
},
"remoteUser": "devel",
"runArgs": [
"--volume=${localWorkspaceFolder}:/workspace:z",
"-e=IMAGE_DEBUG=false"
],
"workspaceFolder": "/workspace"
}
@max06 That's a different Dockerfile-with-features (used to build the base image). Maybe the one I was referring to was already gone from the tmp folder when you checked. Could you rerun "Reopen in Container" and check the log for the latest Dockerfile-with-features' path and post its contents here? Thanks.
@joda01 Could you append the full log (F1
> Dev Containers: Show Container Log
) from when this fails and also append the Dockerfile-with-features file listed in the log?
@samruddhikhandale Do you know where the long list of LABEL
instructions come from in the Dockerfile in https://github.com/microsoft/vscode-remote-release/issues/7308#issuecomment-1274357171? I think we are adding these for the base images, for some reason they are repeated several times.
Good morning @chrmarti
I was able to dig a bit deeper: The problem only seems to occur when the cloned repository is in a docker volume.
I modified one of my debugging repositories to allow easy reproduction for you: https://github.com/max06/ansible-lint-debug You'll find 2 stages in the Dockerfile, stage1 (used as target) and stage2.
Cloning the repository and reopening it in its devcontainer works:
[+] Building 3.5s (15/15) FINISHED
=> [internal] load build definition from Dockerfile-with-features 0.0s
=> => transferring dockerfile: 4.85kB 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> resolve image config for docker.io/docker/dockerfile:1.4 1.1s
=> CACHED docker-image://docker.io/docker/dockerfile:1.4@sha256:9ba7531b 0.0s
=> [internal] load .dockerignore 0.0s
=> [internal] load build definition from Dockerfile-with-features 0.0s
=> [internal] load metadata for mcr.microsoft.com/vscode/devcontainers/p 0.0s
=> [context dev_containers_feature_content_source] load .dockerignore 0.0s
=> => transferring dev_containers_feature_content_source: 2B 0.0s
=> [stage1 1/3] FROM mcr.microsoft.com/vscode/devcontainers/python:0-3.1 0.0s
=> [context dev_containers_feature_content_source] load from client 0.1s
=> => transferring dev_containers_feature_content_source: 276.06kB 0.0s
=> CACHED [stage1 2/3] RUN if [ "lts/*" != "none" ]; then su vscode -c " 0.0s
=> CACHED [stage1 3/3] RUN echo This is stage1 0.0s
=> [dev_containers_target_stage 1/1] COPY --from=dev_containers_feature_ 0.0s
=> exporting to image 0.0s
=> => exporting layers 0.0s
=> => writing image sha256:aba81a7d1b1691ef344c1dca1717338ff972f3c7600b2 0.0s
=> => naming to docker.io/library/vsc-ansible-lint-debug-6dd509058e3aa14 0.0s
=> exporting cache 0.0s
=> => preparing build cache for export 0.0s
It stops after stage1 3/3
- that's the expected result. This also generates the Dockerfile you asked for, attaching it here.
Repeating the process with Clone Repository in container volume
ends up with all stages being built. It might be important: I'm using a remote host, by setting a docker context. I also tried connecting to the ssh target first running the devcontainer extension there, getting the same results. This is the only way for me to test your "Reopen in Container"-functionality.
I'm not sure where your requested Dockerfile gets created when I'm using a docker volume - could be your initial docker container. I'd need further instructions for that...
Edit: One more observation. Using a docker volume in combination with my remote docker context causes red messages during build, complaining about missing docker buildx
. I made sure both my docker clients (locally on Windows and remote on linux) have the buildkit extension installed and ready. The only option left (for me): your initial build container is missing buildkit.
@samruddhikhandale Do you know where the long list of
LABEL
instructions come from in the Dockerfile in #7308 (comment)? I think we are adding these for the base images, for some reason they are repeated several times.
@chrmarti We are adding labels to the images in here. It's strange that they are repeating, I'll take a look.
I'm seeing the same issue. It appears that the multi-stage build is defaulting to the final stage. Is there a way to inspect --target dev_containers_target_stage
?
Thanks.
@max06 Thanks for providing the repository! Unfortunately I can't reproduce the issue with that. Could you retry with Dev Containers (renamed from Remote-Containers) v0.262.1-pre-release? (That also comes with BuildKit installed in the temporary container.)
@chrmarti Using 0.262.1 pre-release paints a different picture.
=> [context dev_containers_feature_content_source] load from client 0.0s
=> => transferring dev_containers_feature_content_source: 276.42kB 0.0s
=> [stage1 2/3] RUN if [ "lts/*" != "none" ]; then su vscode -c "umask 0002 && . /usr/local/share/nvm/nvm.sh && nvm install lts/* 2>&1"; fi 28.0s
=> [stage1 3/3] RUN echo This is stage1 0.4s
=> [dev_containers_target_stage 1/2] COPY --from=dev_containers_feature_content_source . /tmp/build-features/ 0.1s
=> [dev_containers_target_stage 2/2] RUN echo "_CONTAINER_USER_HOME=$(getent passwd root | cut -d: -f6)" >> /tmp/build-features/devcontainer-features.builtin.env && echo "_REMOTE_USER_HOME=$(getent passwd vscode | cut -d: -f6)" >> /tmp/build-features/devco 0.4s
=> exporting to image 0.1s
=> => exporting layers 0.0s
=> => writing image sha256:eef234583e9159f39eb8fa1bd5bd0d833ea04a069676f100b9a76c4ea235b74a 0.0s
=> => naming to docker.io/library/vsc-ansible-lint-debug-f269a658cec8196ad1ca8ea3212fef5e 0.0s
=> exporting cache 0.0s
=> => preparing build cache for export 0.0s
I can no longer see stage2 in there, the issue is gone for me - I've rebuilt my regular project container as well and it's much better now. And I can confirm a functioning buildkit.
Whatever you did in between those 2 versions seems to have fixed it, thank you very much šš¼āāļø
I've just got reminded about a small inconvenience: The notification in the bottom right is stuck at "cloning repository" when building in a docker volume. Nothing bad or to worry about, just a bit irritating. I can open a regular issue for that if needed.
I made a slight modification to the devcontainer.json to put target
within the build
scope, along with updating to v0.262.3, and the correct stage is now built.
Of note, we hadn't touched the devcontainer.json in months and yet target
seemed to previously work as expected, which led me to finding this issue.
In any case, this is now closed for us.
Hey @chrmarti, this issue might need further attention.
@max06, you can help us out by closing this issue if the problem no longer exists, or adding more information.
Nothing more to do here - thanks everyone šš¼āāļø
Type: Bug
Devcontainer built from multistage dockerfile: First stage to be used by vscode, second stage for CI pipeline. Configuration file contains option
build.target: dev
. Option use to work, stopped working now.Extension version: 0.255.2 VS Code version: Code 1.72.0 (64bbfbf67ada9953918d72e1df2f4d8e537d340e, 2022-10-04T23:20:39.912Z) OS version: Windows_NT x64 10.0.22621 Modes: Sandboxed: No Remote OS version: Linux x64 5.15.0-1020-azure
System Info
|Item|Value| |---|---| |CPUs|AMD Ryzen 9 3950X 16-Core Processor (32 x 3493)| |GPU Status|2d_canvas: enabledcanvas_oop_rasterization: disabled_off
direct_rendering_display_compositor: disabled_off_ok
gpu_compositing: enabled
multiple_raster_threads: enabled_on
opengl: enabled_on
rasterization: enabled
raw_draw: disabled_off_ok
skia_renderer: enabled_on
video_decode: enabled
video_encode: enabled
vulkan: disabled_off
webgl: enabled
webgl2: enabled
webgpu: disabled_off| |Load (avg)|undefined| |Memory (System)|63.92GB (25.43GB free)| |Process Argv|--crash-reporter-id 1b0144af-0aee-4e86-b715-64b756167f5e| |Screen Reader|no| |VM|0%| |Item|Value| |---|---| |Remote|Dev Container: Project @ remote_host| |OS|Linux x64 5.15.0-1020-azure| |CPUs|AMD Ryzen 9 3950X 16-Core Processor (32 x 3493)| |Memory (System)|16.69GB (11.75GB free)| |VM|0%|
A/B Experiments
``` vsliv368cf:30146710 vsreu685:30147344 python383:30185418 vspor879:30202332 vspor708:30202333 vspor363:30204092 vslsvsres303:30308271 pythonvspyl392:30443607 vserr242:30382549 pythontb:30283811 vsjup518:30340749 pythonptprofiler:30281270 vshan820:30294714 vstes263:30335439 pythondataviewer:30285071 vscod805cf:30301675 binariesv615:30325510 bridge0708:30335490 bridge0723:30353136 cmake_vspar411:30581797 vsaa593:30376534 pythonvs932:30410667 cppdebug:30492333 vsclangdc:30486549 c4g48928:30535728 dsvsc012cf:30540253 azure-dev_surveyone:30548225 2144e591:30553903 pyindex848cf:30577861 fc301958:30573243 ```Shortened Dockerfile
```Dockerfile ARG VARIANT=3-bullseye # dockerfile_lint - ignore FROM --platform=amd64 mcr.microsoft.com/vscode/devcontainers/python:${VARIANT} as dev LABEL name="DevContainer for Project" LABEL version="1.0.0" # [Choice] Node.js version: none, lts/*, 16, 14, 12, 10 ARG NODE_VERSION="none" RUN if [ "${NODE_VERSION}" != "none" ]; then su vscode -c "umask 0002 && . /usr/local/share/nvm/nvm.sh && nvm install ${NODE_VERSION} 2>&1"; fi # ... only necessary for startup # [Optional] Uncomment this line to install global node packages. # RUN su vscode -c "source /usr/local/share/nvm/nvm.sh && npm install -g ora" 2>&1 # For profile persistence RUN mkdir /home/vscode/.vscode-server && chown vscode.vscode /home/vscode/.vscode-server # [Optional] Just for the CI pipeline FROM dev as ci # ... long running stuff ```shortened devcontainer configuration
```jsonc "build": { "dockerfile": "Dockerfile", "context": "..", "args": { // Update 'VARIANT' to pick a Python version: 3, 3.10, 3.9, 3.8, 3.7, 3.6 // Append -bullseye or -buster to pin to an OS version. // Use -bullseye variants on local on arm64/Apple Silicon. "VARIANT": "3.10-bullseye", // Options "NODE_VERSION": "lts/*" }, "target": "dev" }, ```