vscode-remote-release icon indicating copy to clipboard operation
vscode-remote-release copied to clipboard

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

Open natescherer opened this issue 2 years ago • 20 comments

  • 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?

natescherer avatar Aug 22 '22 21:08 natescherer

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.

chrmarti avatar Aug 25 '22 14:08 chrmarti

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

natescherer avatar Aug 25 '22 18:08 natescherer

Any update on this? It looks like this is a regression according to https://github.com/microsoft/vscode-remote-release/issues/3128.

cseelye avatar Oct 25 '22 22:10 cseelye

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.

davidchisnall avatar Jan 26 '23 11:01 davidchisnall

@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.

cseelye avatar Jan 27 '23 18:01 cseelye

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

This is still broken, any update?

tbsuht avatar Mar 24 '23 08:03 tbsuht

We removed --pull when using an image when BuildKit is not installed to fix https://github.com/devcontainers/cli/issues/60. I suggest you install BuildKit.

chrmarti avatar Apr 03 '23 10:04 chrmarti

@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

tbsuht avatar Apr 03 '23 13:04 tbsuht

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

chrmarti avatar Apr 04 '23 13:04 chrmarti

@chrmarti Any idea when a fix can be expected?

tbsuht avatar Apr 11 '23 08:04 tbsuht

@chrmarti Any news?

tbsuht avatar May 05 '23 09:05 tbsuht

@chrmarti push

tbsuht avatar Jun 22 '23 09:06 tbsuht

@chrmarti push

tbsuht avatar Aug 03 '23 07:08 tbsuht

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

appleoddity avatar Oct 13 '23 20:10 appleoddity

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

thoughtfuldata avatar Nov 12 '23 11:11 thoughtfuldata

Same issue here.

huxuan avatar Feb 05 '24 01:02 huxuan

This would be nice to have

SkinnyPigeon avatar Feb 05 '24 11:02 SkinnyPigeon

Same issue. Any workarounds ?

gurvinder-dhillon avatar Feb 16 '24 04:02 gurvinder-dhillon

Same issue. Any workarounds ?

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

huxuan avatar Feb 16 '24 07:02 huxuan

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: @.***>

cseelye avatar Feb 16 '24 12:02 cseelye