vscode-remote-release

vscode-remote-release copied to clipboard

There has been a surprising amount of interest in having devcontainer.json reference and open a .code-workspace by default when reopen folder in container using Remote - Containers or in a codespace. While there is a workaround, it breaks the "it's ready to go when you create a dev container" promise.

@egamma I'm curious, what would be the current workaround for automating this that you are referring to? Is it somehow possible to call remote-containers.openFolder with an uri parameter from a dummy folder opened in order to build the container?

Another thing that would go hand in hand with this feature would be the ability to specify .devcontainer.json location in VSCode settings so that once you auto open your workspace file (which might be in an arbitrary location within the container) any modifications to the container image get picked up. Right now I'm symlinking the needed files in a generated workspace file's directory, but that seems kind of hacky (details here).

Here's a specific use case:

• the multi-root workspace lives exclusively in the container, nothing makes it to the host.

• the projects in the workspace come from two different named volumes:

  • one app volume with application components and the .code-workspace file.
  • one libs volume with with shared libraries (this can be mounted on other containers too, hence the split).

• the app volume is the workspaceMountFolder, the libs volume is mounted elsewhere.

• the .code-workspace file brings together projects from both volumes in the flat layout of multi-root workspaces.

The transition from host to container would be seamless if the .code-workspace in the workspaceMountFolder opened automatically.

@dslijepcevic I see that @egamma never got back to you. Did you ever figure out how to auto open a code-workspace file when the devcontainer opens? Thanks!

@chrmarti This got unassigned from the Sep 2020 milestone and then kind of looks like it got buried as it's been 2 years now. Is the intent to get this done at some point, or should I give up?

@sarg3nt The feature request makes sense. It just hasn't made it on our plans, so we don't have an ETA. (There are workarounds: Open the multi-root workspace locally and then reopen in container or the other way around.)

I really hope this makes it into your plans soon. Monorepos could really benefit from this and it's the only thing holding a project of mine back from making the switch to devcontainers.

this would be very helpfull :)

I am a big fan of this. Pleeeeeease make it happen.

+1 My team got really confused when they had to do the triple jump: local -> ssh -> docker -> workspace People accidentally open workspace before opening docker container and that is very difficult to back out. The issue also compounds when it leaves a record in the "Open Recent" list. Even after one successfully performed the triple jump, it's likely in the future they will accidentally open the workspace (outside of docker) by picking the wrong item in the "Open Recent" list.

Please consider supporting a default workspace in the devcontainer.json.

Thanks!

Any update on this? We really need this (and would gladly pay a bounty for making this happen)

An enthusiastic +1 to this from me also 😃

We have since moved all VS Code specific properties to "customizations"."vscode" in the devcontainer.json. We could add the workspace file's path there. The Dev Containers extension would then read it when reopening the window.

@chrmarti Can you mention which settings in customizations.vscode.settings let you do this?

@chrmarti I'm also interested in the answer to @souryavarenyas question.

The OP states "a surprising amount of requests" but this shouldn't be surprising if you've ever used gitpod, a competitor to codespaces. Gitpods equivalent to Github Codespaces' .devcontainer.json is called .gitpod.yml and you can specify a .code-workspace file. This is really useful in combination with the .gitpod.yml as you can auto clone other repositories into your container and it will add those folders to vscode file explorer which makes working with multi-repo projects extremely nice. I personally have (private) repos with all my devenv configuration stuff so that it doesn't crowd my (public or private) project repos.

Multi Repos hasn't been a focus of codespaces until recently (at least publically) so I hope that this added use case gives some clarity to the increase in demand.

@souryavarenya @slimcdk under customizations.vscode you can put the content of your whole code-workspace file basically (settings, folders, extensions, etc.)

This replace the code-workspace for your devcontainer

customizations.vscode only supports settings and extensions at the moment. The request to support a .code-workspace file still makes sense.

@chrmarti folders works too

@chrmarti folders works too

doesn't for me

For me, tasks and launch are the important ones.

+1 to having a way to specify a .code-workspace file to automatically open a workspace when connecting to a container. Everything else is trivially easy to get up and running in our project with the one exception of finding and opening (in our case) a multi-root workspace which is essential to our workflow.

Any movement on this? Would really appreciate this, since it causes situations that are hard to recover from for inexperienced users.

@chrmarti folders works too

doesn't for me

I found this thread trying to understand how to get a .code-workspace file to be opened by default in a devcontainer, but I actually think being able to manipulate the folders "config" (?) is what I am looking for.... apart from the monorepo type use case, I am also trying to add a azure storage container via the Microsoft vscode Azure extensions

[!WARNING] I think the output of code --status changed to longer make it possible to detect which windows are open, making this no longer a viable workaround.

Original comment

After a lot of iteration, for anybody that wants a workaround to make opening the workspace basically foolproof for people using the container, I've figured out what I think is actually a decent way to reopen the container in the workspace automatically the first time an interactive shell is opened after the container started, whether or not it's in a workspace.

Make sure to replace <project-name> with your project name as you want it to appear in VS Code's title bar and recently opened list.

First, I have my devcontainer.json looking like this. I use ${containerWorkspaceFolder} so the installed folder on the host machine doesn't matter:

{
    // ...
    "containerEnv": {
        "WORKSPACE_FILE": "${containerWorkspaceFolder}/<project-name>.code-workspace",
        "WORKSPACE_BASHRC": "${containerWorkspaceFolder}/.devcontainer/bashrc.sh"
    },
    "postCreateCommand": "${containerWorkspaceFolder}/.devcontainer/postCreateScript.sh",
    "postStartCommand": "${containerWorkspaceFolder}/.devcontainer/postStartScript.sh",
    // ...
}

Inside postCreateScript.sh, I append the user's .bashrc to make sure my own script gets run for every new interactive shell:

#!/bin/bash

set -euo pipefail

cat <<EOF >> ~/.bashrc
# Generated from dev container in $(basename "$0")
source "\$WORKSPACE_BASHRC"
EOF

Inside postStartScript.sh, since I want this to make sure the workspace is checked every time the container is started, I clean up a file I use to check that:

#!/bin/bash

set -euo pipefail

rm --force ~/.workspace-opened

Finally, in bashrc.sh, if that file is:

1. not yet present, ensuring the workspace is checked once every time the container starts but not on every single interactive shell and
2. the workspace is not currently open, in case the dev container has been started directly in the workspace, e.g. from the "Recents" menu

I reopen the current non-workspace container in the workspace:

check_workspace () {
    workspace_base_filename=$(basename "$WORKSPACE_FILE")
    workspace_name=${workspace_base_filename%.*}
    current_windows=$(code --status | grep --extended-regexp "window \[[0-9]+\]")
    if ! echo "$current_windows" | grep --fixed-strings --quiet "$workspace_name (Workspace)"; then
        if ! code --reuse-window "$WORKSPACE_FILE"; then
            echo "Failed to open workspace" >&2
            return 1
        fi
    fi
    
    touch ~/.workspace-opened
}

if ! [ -f ~/.workspace-opened ]; then
    check_workspace
fi

It would be really nice to have this as a feature some day and not need to jump through these hoops. We heavily depend on multi-root workspaces and we can't find another way to make things nice with dev containers otherwise.

I'm a bit new to devcontainers but I solved multi root like this, not sure if there is a problem with this approach

select/create a project folder (docker volume probably) and mount everything you want there. Then set it as workspacefolder. like:

 "mounts": [
    "source=/.../folder1,target=/projectFolder/folder1,type=bind",
    "source=/.../folder2/,target=/projectFolder/folder2,type=bind",
],
"workspaceFolder": "/projectFolder",

I always open the container in vscode using CLI, devcontainer open

not sure if there is a problem with this approach

@Kaptensanders In your setup, I'm guessing you have devcontainer.json version controlled in one of the nested folders i.e. either folder1 or folder2 and you don't need any other multi-root VS Code features specific to those nested folders?

Since you're not actually opening a workspace file with what you've shared and I think setting workspaceFolder just treats it implicitly as a single-folder workspace, you would be missing improved multi-root workspace support for explorer, search, command palette, git, etc. for each of the subfolders. It would be more or less the same thing as having /projectFolder be the git repo and putting devcontainer.json in that and not specifying workspaceFolder.

not sure if there is a problem with this approach

@Kaptensanders In your setup, I'm guessing you have devcontainer.json version controlled in one of the nested folders i.e.

Yes, I open vscode with devcontainer open from within the subfolder/repo that contains .devcontainer/devcontainer.json.

and you don't need any other multi-root VS Code features specific to those nested folders? As it is a backend-frontend setup split into two different repos it would be nice, but no. Probably I could specify some support for building project2 in project1/.vscode folder, but no I don't really need it.

Since you're not actually opening a workspace file with what you've shared and I think setting workspaceFolder just treats it implicitly as a single-folder workspace, you would be missing improved multi-root workspace support for explorer, search, command palette, git, etc. for each of the subfolders.

supported vscode customizations from the devcontainer.json are loaded and for tasks etc to work, I mount the .vscode folder in the workspaceFolder root

It would be more or less the same thing as having /projectFolder be the git repo and putting devcontainer.json in that and not specifying workspaceFolder.

Not sure, haven't tried. But without setting the workspaceFolder to the repos parent, how would I get vscode to show me the other mounted folders?

U can see it here https://github.com/Kaptensanders/skolmat/blob/main/.devcontainer/devcontainer.json

It works as a hack substitute for real .code-workspace support. I'm sure I'm missing out on some things but I'm not the most advanced user.

Not sure if this is useful to everyone, but I think I found a reasonable solution.

Install this extension in the dev container:

Documentation to that Extension.

Now, add in the root directory of your workspace a .vscode folder with a settings.json:

The result is: If someone opens the dev container normally, the settings.json in root is used, the setting tells the extension to auto-open the first code-workspace file and the extension does that.

Still not that nice... After all, everything gets loaded, then the extension gets initialized, opens the code workspace, everything gets unloaded, and then everything gets loaded/initialized one final time.

After some serious head scratching I put together a script that fixes this, it opens a vscode workspace within a devcontainer. https://gist.github.com/Kaptensanders/79da7c1547751fb43c75904e3110bbf9

Anyone here about any progress for this? The script is nice, but we're not really looking to implement a workaround we'll have to maintain.