Improved workflow- scan for devcontainer configs in a workspace, and provide options to open them.

[mxdmedia]

Currently, when you click on the Remote Host button (green button in the lower left corner) when the current window is not connected to anything remote, you get options for Remote Containers: Reopen folder in container, Remote Containers: Open folder in container.. etc. This is great for initial setup, but once you have all of your remote containers set up, launching them can be a bit cumbersome.

I think this workflow (after setup) could be greatly improved, if VSCode were to scan the current non-connected workspace for any .devcontainer configs in its tree, and provide those as options, using the "name" parameter in the found devcontainer.json files. Additionally it would be nice to select "Open in new window", "Open in current window" and even "Open all".

Combined with allowing specific services from a docker-compose file to be launched, as proposed in #211 , this would be an amazing workflow, for those of us who deal with monorepo type setups. An example. Lets say I have a monorepo for a project that includes the server-api code (Dependent on a database) and the client web-app code, and I have set up an appropriate set of root-level docker configurations for my developers. Lets say I have a root docker-compose.yml that looks like:

version: '3'

services:
  db:
    restart: always
    image: postgres:10.5
    # more params for volumes, server launch, ports, etc..

  dev-api:
    depends_on:
      - db
    build: ../api-server/my-api
    # more params for volumes, server launch, ports, etc..

  dev-client:
    image: dev-client
    build: ../client/my-app
    # more params for volumes, server launch, ports, etc..

This is intended to allow a developer to fire up a local version of the api, and a local version of the web app for development. Notice- the dev-api service is dependent on the db service. I could then go into each service's source directory, and create an appropriate .devcontainer directory. If I could then specify only the services to launch (e.g.- launch 'dev-client' for the client code, and 'dev-api' for the api code (which should also launch 'db' as it is dependency) in the appropriate .devcontainer files, and if scanning/launching from the Remote Host button existed, I would then have the following workflow:

1. Open my project in VSCode.
2. VSCode scans for my .devcontainer configs.
3. After scanning, I click on the Remote Host button. I see 5 options at the top: Remote Container: Open Dev API in new window, Remote Container: Open Dev API in this window, Remote Container: Open Dev Client in new window, Remote Container: Open Dev Client in this window, and Remote Container: Open All Containers.
4. I click Remote Container: Open Dev API in new window.
5. VSCode opens a new window, launches the dev-api service (and docker launches the dependent db service), and attaches it to the window. Now I can edit/debug my api.
6. When I close the window, it shuts down the services launched for that particular workspace.
7. Alternatively, I could click "Remote Container: Open all containers" which would launch a new window for each service, spin up the service, and attach to it.

Once this was set up, it would, IMO, be a great workflow.

[bamurtaugh]

Hey there, thanks for writing up a great issue. I think the core suggestion is along the lines of #1460, to suggest connecting to multiple containers depending on the division/needs of your workspace.

If it looks like the suggestion is related/the same, I would suggest merging this content into that thread (as that one happens to have 39 upvotes) so that we can track feedback more effectively, and I'll then close this thread. Please let me know if I may be misreading anything or if you have any other thoughts or feedback!

[mxdmedia]

Thanks @bamurtaugh . It looks like #1460 is looking for the same outcome, and I agree that merging the issues together would be ideal. It looks like there is a link in that issue due to your comment here. I would also be happy to post a comment in that issue linking back here, if that would be beneficial.

[bamurtaugh]

@mxdmedia You're right, since I commented the issue number here, they are linked!

Copying over your comment is totally your call- if you feel like anything you mentioned above might not have been captured in that issue, you could include a comment with any other info. Thanks again 😄