microsoft / microsoft/vscode-remote-release
Add inline action to delete 'Attached Container' config files
@chrmarti is already working on this.
Since Jan 11, 2022.
- Dominant language
- Dockerfile
- Stars
- 4.2k
- Forks
- 470
- Avg merge
- 1d 1h
- Merged PRs (30d)
- 1
Description
Hi,
I recently started to use docker again and am amazed at how this extension works. of course, there is room for improvements as well as problems we users haven't expected.
In my case, it is trying to work in vscode attached to two different containers from the same base image. repro steps tell everything I guess.
this behavior is not happening when I juggle between workspaces in different containers created from different base images. I used 2 node:16-alpine and 1 node:17-alpine container.
I hope it is not something hard to fix and ears find happiness away from the error/warning bell.
YILMAZ
PS: just before submitting, I noticed this may be (just a maybe) fixed by changing the way you are using the names of the image and the container. workspace names are like "Test [container node:16-alpine (firebase)]" and I would expect to see something like this instead: "Test [firebase (node:16-alpine)]" (container name: firebase, base image: node:16-alpine).
Does this occur consistently?
YES
Repro steps:
- create two containers from the same base image (base alpine should suffice) with different names (obviously :) but needed to stress it out)
- create two workspaces with different names on each.
- run vscode, from docker extension attach to one of the running containers. let's call t container-1
- wait for the new vscode to spawn attached and "open folder" to the workspace on that container. let's call it workspace-1
- close this vscode by "exit" or "close connection" without closing the workspace.
- now attach vscode to other container and a newly attached vscode will spawn
- once the connection is established, you are greeted with "workspace does not exists" pointing to the workspace in container-1.
- close the warning, then open the workspace in this container. let's say workspace-2 in container-2.
- now close this attached vscode to again get into container-1 and get the same "not exists" message and browse to workspace-1 manually.
- endure this whenever you want to attach to "the other" container.
Expected:
- the workspace used in a container is saved for that container and reopened when I connect/attach to that container.
- or the workspace is saved into the container and offered to be reopened when I connect/attach to that container instead of trying to reopen some last seen.
Version: 1.18.0
OS: Windows 10 64bit
OS Release: 10.0.19044
Product: Visual Studio Code
Product Version: 1.63.2
Language: en
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.