Linux: 'Rebuild Container Without Cache' doesn't re-pull image when using 'image' in devcontainer.json

[natescherer]

• VSCode Version: 1.70.2
• Local OS Version: Win 10 21H1
• Remote OS Version: Debian 11
• Remote Extension/Connection Type: Containers
• Logs:

Steps to Reproduce:

1. Attempt to use 'Rebuild Container Without Cache' on a devcontainer.json that uses 'image' and not 'dockerFile'

Does this issue occur when you try this locally?: Yes
Does this issue occur when you try this locally and all extensions are disabled?: Yes

Hello! I've noticed that calling 'Rebuild Container Without Cache' only works properly when the devcontainer.json is using 'dockerFile' and not 'image'. When the json file is using a Dockerfile, the container is fully rebuilt, but when it is just using 'image', no rebuild occurs and the container just restarts. Is this intentional?

[chrmarti]

It should remove the current container and create a new one. Does that not work? E.g., you can check with docker ps -a that the container id changed to verify it is a new container.

[natescherer]

Sorry for the confusion, I confirmed it does make a new container but it does not re-pull the image the same way it does as if you are using a Dockerfile.

Attached are logs of the docker ps and
the rebuild log from inside vscode.
dockerps.txt
rebuild_without_cache.txt

[cseelye]

Any update on this? It looks like this is a regression according to #3128.

[davidchisnall]

We are hitting the same issue. We ship a container image that contains the tools required to build our project. When we roll out a new version of the tools, the workflow for users is:

1. Stop the dev container in VS Code
2. Open Docker Desktop
3. Delete the container
4. Delete the image
5. Reopen the workspace in VS Code

Ideally the workflow would be for our our dev container configuration to specify that the tools might be updated and for VS Code to periodically (or when explicitly triggered by the user) poll the container registry for a newer version and give users the option to update if they don't have the latest version, then recreate the container.

[cseelye]

@davidchisnall A workaround I have been using in this case to help improve that workflow for my team, is to add an "initializeCommand" to devcontainer.json that pulls the most recent image (docker pull devcontainerimagename:latest) every time, along with publishing the dev container images using a single known tag ("latest" or whatever you prefer). It's not perfect, but it means that you can use "Dev Containers: Rebuild Container Without Cache", or just restart vscode, instead of all of the steps you outlined.

[tbsuht]

Any update on this? It looks like this is a regression according to #3128.

This is still broken, any update?

[chrmarti]

We removed --pull when using an image when BuildKit is not installed to fix devcontainers/cli#60. I suggest you install BuildKit.

[tbsuht]

@chrmarti I'm using BuildKit now, but still the image is not updated when using 'Rebuild without Cache'. Or am I missing something?

[1180 ms] Start: Check Docker is running
[1180 ms] Start: Run in Host: docker version --format {{.Server.APIVersion}}
[1207 ms] Server API version: 1.41
[1207 ms] Start: Run in Host: docker volume ls -q
[1228 ms] Start: Run in Host: docker inspect --type container db6a2e925955bafe45f7f335ec36ec21364b05423b838197bef11a754eec8788
[1248 ms] Start: Run in Host: docker ps -q -a --filter label=vsch.local.folder=\\wsl.localhost\TEST\home\user\dev\my-dev --filter label=vsch.quality=stable
[1272 ms] Start: Run in Host: docker ps -q -a --filter label=devcontainer.local_folder=\\wsl.localhost\TEST\home\user\dev\my-dev --filter label=devcontainer.config_file=/home/user/dev/my-dev/.devcontainer/devcontainer.json
[1293 ms] Start: Run in Host: docker ps -q -a --filter label=devcontainer.local_folder=\\wsl.localhost\TEST\home\user\dev\my-dev
[1313 ms] Start: Run in Host: docker ps -q -a --filter label=devcontainer.local_folder=\\wsl.localhost\TEST\home\user\dev\my-dev
[1339 ms] Start: Run in Host: /home/user/.vscode-remote-containers/bin/7f329fe6c66b0f86ae1574c2911b681ad5a45d63/node /home/user/.vscode-remote-containers/dist/dev-containers-cli-0.288.0/dist/spec-node/devContainersSpecCLI.js up --container-session-data-folder /tmp/devcontainers-54f00338-1f30-48b1-8782-5b21fc91c7571680527777889 --workspace-folder /home/user/dev/my-dev --workspace-mount-consistency cached --id-label devcontainer.local_folder=\\wsl.localhost\TEST\home\user\dev\my-dev --id-label devcontainer.config_file=/home/user/dev/my-dev/.devcontainer/devcontainer.json --log-level debug --log-format json --config /home/user/dev/my-dev/.devcontainer/devcontainer.json --default-user-env-probe loginInteractiveShell --build-no-cache --mount type=volume,source=vscode,target=/vscode,external=true --mount type=bind,source=/mnt/wslg/runtime-dir/wayland-0,target=/tmp/vscode-wayland-1f6161f9-9e43-4f3f-a63d-fd446040ef7d.sock --skip-post-create --update-remote-user-uid-default on --mount-workspace-git-root true
[1524 ms] @devcontainers/cli 0.35.0. Node.js v16.14.2. linux 5.15.79.1-microsoft-standard-WSL2 x64.
[1524 ms] Start: Run: docker buildx version
[1583 ms] github.com/docker/buildx v0.10.0-docker 876462897612d36679153c3414f7689626251501
[1583 ms] 
[1583 ms] Start: Resolving Remote
[1587 ms] Start: Run: git rev-parse --show-cdup
[1592 ms] Start: Run: docker ps -q -a --filter label=devcontainer.local_folder=\\wsl.localhost\TEST\home\user\dev\my-dev --filter label=devcontainer.config_file=/home/user/dev/my-dev/.devcontainer/devcontainer.json
[1613 ms] Start: Run: docker inspect --type image artifactory.my-url.com/my-repo-docker-dev-local/my-container:latest
[1640 ms] local container features stored at: /home/user/.vscode-remote-containers/dist/dev-containers-cli-0.288.0/dist/node_modules/vscode-dev-containers/container-features
[1642 ms] Start: Run: tar --no-same-owner -x -f -
[1659 ms] Start: Run: docker build -f /tmp/devcontainercli-user/updateUID.Dockerfile-0.35.0 -t vsc-my-dev-2d0fbffd56b6df1da9aa3116c56208a4dd64b0fb2cc7c435e0142dc865c0c975-uid --build-arg BASE_IMAGE=artifactory.my-url.com/my-repo-docker-dev-local/my-container:latest --build-arg REMOTE_USER=user --build-arg NEW_UID=1000 --build-arg NEW_GID=1000 --build-arg IMAGE_USER=root /tmp/devcontainercli-user/empty-folder

[chrmarti]

@tbsuht You're right, this is a bug when we use the updateUID.Dockerfile on Linux.

[tbsuht]

@chrmarti Any idea when a fix can be expected?

[tbsuht]

@chrmarti Any news?

[tbsuht]

@chrmarti push

[tbsuht]

@chrmarti push

[appleoddity]

Still an issue....vscode should be checking for a new image version on a rebuild without cache.

[thoughtfuldata]

I am not sure if this is the same issue (image not being refreshed) but this happens to me as well.

I use a Dockerfile however

e.g Even when I use "Rebuild Container without Cache," I am currently having to update the image manually on Docker Desktop by using "Pull." If not, the next time I use "Rebuild Container" it uses the older image

[huxuan]

Same issue here.

[SkinnyPigeon]

This would be nice to have

[gurvinder-dhillon]

Same issue. Any workarounds ?

[huxuan]

Same issue. Any workarounds ?

Currently, we can explictly have the docker pull command as initializeCommand.

[cseelye]

We’ve been using that same workaround for the past year. On Feb 16, 2024, at 2:40 AM, Xuan (Sean) Hu ***@***.***> wrote: Same issue. Any workarounds ? Currently, we can explictly have the docker pull command as initializeCommand. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[jonbackhaus]

Confirmed that the issue still exists, even when using a Dockerfile.

.devcontainer.json code snippet:

{
  "build": {
    "dockerfile": "Dockerfile",
    "args": {
      "IMAGE_URL": "mcr.microsoft.com/devcontainers/base",
      "IMAGE_TAG": "bullseye"
    }
  }
}

Dockerfile:

ARG IMAGE_URL="mcr.microsoft.com/devcontainers/base"
ARG IMAGE_TAG="debian"
FROM ${IMAGE_URL}:${IMAGE_TAG}

Rebuild Container without Cache does not pull the latest image in this case; it uses the existing image on the host.

[t3hk0d3]

Bump. This is annoying!

[SkinnyPigeon]

@huxuan workaround does the job. We did it with a docker pull <our image> but we also added a docker image prune --filter 'label=<our image> -f to keep the local registry empty of redundant images