-
Notifications
You must be signed in to change notification settings - Fork 283
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow a default ".code-workspace" file to open to be specified in devcontainer.json #1124 #3665
Comments
@egamma I'm curious, what would be the current workaround for automating this that you are referring to? Is it somehow possible to call Another thing that would go hand in hand with this feature would be the ability to specify |
Here's a specific use case:
The transition from host to container would be seamless if the |
@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? |
@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 Please consider supporting a default workspace in the 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 |
@chrmarti Can you mention which settings in |
@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 This replace the code-workspace for your devcontainer |
|
@chrmarti folders works too |
doesn't for me |
For me, |
+1 to having a way to specify a |
When opening https://github.com/github/codespaces-codeql/ in a codespace, it's easy to miss the prompt that tells you to open the tutorial.code-workspace file. In fact people actively dismiss the alert to get it out of the way. If you miss that prompt, you end up with a single-rooted workspace, which causes various other problems. While there is an open issue to allow VS Code to open a default workspace [1], there doesn't seem to have been any progress on it in the last two years. So we're taking matters into our own hands and forcing the extension to open the tutorial workspace, if it detects it. This will only happen if the following three conditions are met: - the .tours folder exists - the tutorial.code-workspace file exists - the CODESPACES_TEMPLATE setting hasn't been set NB: the `CODESPACES_TEMPLATE` setting can only be found if the tutorial.code-workspace has already been opened. So it's a good indicator that we're in the folder, but the user has ignored the prompt. [1]: microsoft/vscode-remote-release#3665
When opening https://github.com/github/codespaces-codeql/ in a codespace, it's easy to miss the prompt that tells you to open the tutorial.code-workspace file. In fact people actively dismiss the alert to get it out of the way. If you miss that prompt, you end up with a single-rooted workspace, which causes various other problems. While there is an open issue to allow VS Code to open a default workspace [1], there doesn't seem to have been any progress on it in the last two years. So we're taking matters into our own hands and forcing the extension to open the tutorial workspace, if it detects it. This will only happen if the following three conditions are met: - the .tours folder exists - the tutorial.code-workspace file exists - the CODESPACES_TEMPLATE setting hasn't been set NB: the `CODESPACES_TEMPLATE` setting can only be found if the tutorial.code-workspace has already been opened. So it's a good indicator that we're in the folder, but the user has ignored the prompt. [1]: microsoft/vscode-remote-release#3665
When opening https://github.com/github/codespaces-codeql/ in a codespace, it's easy to miss the prompt that tells you to open the tutorial.code-workspace file. In fact people actively dismiss the alert to get it out of the way. If you miss that prompt, you end up with a single-rooted workspace, which causes various other problems. While there is an open issue to allow VS Code to open a default workspace [1], there doesn't seem to have been any progress on it in the last two years. So we're taking matters into our own hands and forcing the extension to open the tutorial workspace, if it detects it. This will only happen if the following three conditions are met: - the .tours folder exists - the tutorial.code-workspace file exists - the CODESPACES_TEMPLATE setting hasn't been set NB: the `CODESPACES_TEMPLATE` setting can only be found if the tutorial.code-workspace has already been opened. So it's a good indicator that we're in the folder, but the user has ignored the prompt. [1]: microsoft/vscode-remote-release#3665
When opening https://github.com/github/codespaces-codeql/ in a codespace, it's easy to miss the prompt that tells you to open the tutorial.code-workspace file. In fact people actively dismiss the alert to get it out of the way. If you miss that prompt, you end up with a single-rooted workspace, which causes various other problems. While there is an open issue to allow VS Code to open a default workspace [1], there doesn't seem to have been any progress on it in the last two years. So we're taking matters into our own hands and forcing the extension to open the tutorial workspace, if it detects it. This will only happen if the following three conditions are met: - the .tours folder exists - the tutorial.code-workspace file exists - the CODESPACES_TEMPLATE setting hasn't been set NB: the `CODESPACES_TEMPLATE` setting can only be found if the tutorial.code-workspace has already been opened. So it's a good indicator that we're in the folder, but the user has ignored the prompt. [1]: microsoft/vscode-remote-release#3665
When opening https://github.com/github/codespaces-codeql/ in a codespace, it's easy to miss the prompt that tells you to open the tutorial.code-workspace file. In fact people actively dismiss the alert to get it out of the way. If you miss that prompt, you end up with a single-rooted workspace, which causes various other problems. While there is an open issue to allow VS Code to open a default workspace [1], there doesn't seem to have been any progress on it in the last two years. So we're taking matters into our own hands and forcing the extension to open the tutorial workspace, if it detects it. This will only happen if the following three conditions are met: - the .tours folder exists - the tutorial.code-workspace file exists - the CODESPACES_TEMPLATE setting hasn't been set NB: the `CODESPACES_TEMPLATE` setting can only be found if the tutorial.code-workspace has already been opened. So it's a good indicator that we're in the folder, but the user has ignored the prompt. [1]: microsoft/vscode-remote-release#3665
Any movement on this? Would really appreciate this, since it causes situations that are hard to recover from for inexperienced users. |
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 |
Warning I think the output of Original commentAfter 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 First, I have my {
// ...
"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 #!/bin/bash
set -euo pipefail
cat <<EOF >> ~/.bashrc
# Generated from dev container in $(basename "$0")
source "\$WORKSPACE_BASHRC"
EOF Inside #!/bin/bash
set -euo pipefail
rm --force ~/.workspace-opened Finally, in
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:
I always open the container in vscode using CLI, |
@Kaptensanders In your setup, I'm guessing you have Since you're not actually opening a workspace file with what you've shared and I think setting |
Yes, I open vscode with
supported vscode customizations from the devcontainer.json are loaded and for tasks etc to work, I mount the .vscode folder in the workspaceFolder root
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 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. |
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. |
I'm also looking for this feature, every time i open my DEV container i then have to go and select the workspace file to use... |
Eager to see a solution here as well! |
This would be great to have. We've standardized on dev containers, but in repos with multiple python projects we use multi-root workspaces so each project can have its own virtualenv / python interpreter. The goal of the devcontainer configuration is so developers don't have to worry about "doing the right thing", so we don't want them to have to know to open a code workspace file. We're currently using the above mentioned extension and while it works, it would be great to avoid the extra "load and then reload" cycle. |
Hi, ¿How is this going? I was searching and encountered this issue which I face exactly the same problem, postStartCommand generates a workspace which I have to manually open after vscode has started in the open menu, on the toolbar above. Is there any workaround? Or fot the moment we still need to do the "Load and the Reload". |
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.The text was updated successfully, but these errors were encountered: