ref: https://github.com/microsoft/vscode-remote-release/issues/387
Currently, multi root workspaces with remote container just allows us to open via single container.
I'd like to propose support to open container per directory.
Let's say we have a monorepo which has backend API and frontend.
monorepo/
monorepo.code-workspace
backend/
.devcontainer/
Dockerfile
devcontainer.json
docker-compose.yml
frontend/
.devcontainer/
Dockerfile
devcontainer.json
docker-compose.yml
monorepo.code-workspace is like the following:
{
"folders": [
{
"path": "backend"
},
{
"path": "frontend"
}
]
}
And when we run Open Workspace in Container, both backend container and frontend container start as defined in backend/devcontainer.json and frontend/devcontainer.json individually.
// fyi @Chuxel @chrmarti
Any news on this feature, please?
I think I have another use case for this feature request. For example, I would like to have a repo which contains cross-platform code (e.g. code that is built for 3 major platforms: Windows, Linux, Mac). If a developer syncs the code on a Mac machine, it would allow building on the Mac container. If he/she syncs on a Windows machine, then it would allow building on the Windows container.. and so on.
clientrepo/
client.code-workspace
build-windows/
.devcontainer/
Dockerfile
devcontainer.json
docker-compose.yml
build-linux/
.devcontainer/
Dockerfile
devcontainer.json
docker-compose.yml
build-mac/
.devcontainer/
Dockerfile
devcontainer.json
docker-compose.yml
src
This would also require support for Windows and Mac containers:
https://github.com/microsoft/vscode-remote-release/issues/445
How to activate WhatsApp Web or WhatsApp business of a distant person via a
mobile number only
>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode-remote-release/issues/1460#issuecomment-631254998,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/APUECRPJ6P6VOTTQSV6T7F3RSNWWZANCNFSM4IZIF7KA
.
The opensource community is moving into monorepo style for the last couple of years already, currently don't see any way to use this. How can you use VSCode Remote Code Development due to use cases described below?
if we have 20 microservices in monorepo, we can't run 20 VSCode windows (+ frontend). You should have this as a must-have feature before public release.
Thanks
@XBeg9 It's important to separate general use cases with mono repos from this specific request. Certainly monorepos are popular in certain OSS circles, but that should not be blocked by this in most cases. So, let's get a better understanding of what you are trying to do to make sure there isn't another feature request beyond this one.
To be clear, when cloned locally, you can absolutely have sub-folders in a monorepo that you open in a container and these folders can depend on other things in the broader source tree. (Even if you just use a Dockerfile, the entire git repository is mounted by default. The specific request here is to have support for creating a .code-workspace where you are working with multiple containers concurrently in the same VS Code UI instance.) You can also open a VS Code window as you need to a different container started up using the same docker-compose.yml file. See here.
In your example, would an individual developer be running 21 containers locally at once and would want to connect to all of them at the exact same time from a single VS Code window?
Remote - Containers is also released, are you referring to Codespaces?
@Chuxel thanks for the detailed answer. Yea, probably I mess around with Codespaces and Remote - Containers (release status).
The specific request here is to have support for creating a .code-workspace where you are working with multiple containers concurrently in the same VS Code UI instance.
That's exactly what I referring to, is there a way to run single VSCode UI with multiple devcontainers?
We don't need to run all 20 at once, but I want to have a debugger connected to as many as I want on the same VSCode UI instance. In monorepo, we are sharing lots of core/module packages with backend and frontend services.
@Chuxel I've seen that documentation and got so confused, in a title it says Connecting to multiple containers at once, but then in the To connect to both it requires me to open multiple windows.
If we are talking about working in monorepo style, so I am edition some core or shared modules, used by multiple services containers, should I go across multiple windows to validate my changes?
I've seen that documentation and got so confused, in a title it says Connecting to multiple containers at once, but then in the To connect to both it requires me to open multiple windows. If we are talking about working in monorepo style, so I am edition some core or shared modules, used by multiple services containers, should I go across multiple windows to validate my changes?
@XBeg9 This is referring to how one would spin up multiple Docker Compose managed containers that need to run at the same time for the application to work and develop each of them concurrently.
To recap what is possible in Remote - Containers, you can spin up a bunch of containers using the same docker-compose.yml and open individual ones with unique devcontainer.json contents (E.g. extensions) in separate VS Code windows. You can do this whenever you need to work with a given container in the set, not just right away. That's what is described in the link above. You can even have scenario specific docker-compose.yml files if needed - just use a different starting folders for the first thing you open.
Unfortunately, Codespaces does have some limitations around monorepos currently that prevent it from doing this, but that team knows about the issue. So, if you were trying it there, you're totally right that there's not way to do it yet (which is why I'd asked given your description). That is tracked here if you want to upvote / comment there: https://github.com/MicrosoftDocs/vscodespaces/issues/206
Now, shared libraries / modules is an interesting use case for Remote - Containers. There's a couple things here:
.code-workspace file within the same container without issue. So, if the toolchain for "shared" and each service is the same, you can create a workspace per service that includes both. (Or one big container for that matter.)Otherwise, yes, you'd be running separate windows if neither of these two apply or would work.
Most helpful comment
The opensource community is moving into monorepo style for the last couple of years already, currently don't see any way to use this. How can you use VSCode Remote Code Development due to use cases described below?
if we have 20 microservices in monorepo, we can't run 20 VSCode windows (+ frontend). You should have this as a must-have feature before public release.
Thanks