microsoft / vscode-remote-release

Visual Studio Code Remote Development: Open any folder in WSL, in a Docker container, or on a remote machine using SSH and take advantage of VS Code's full feature set.
https://aka.ms/vscode-remote
Other
3.68k stars 296 forks source link

Dynamically load/create env vars on a per-project & per-machine basis #10405

Open ath opened 1 month ago

ath commented 1 month ago

In the devcontainer.json file, I want to mount a local directory, specifically my SSH folder, into the container. This initially seems straightforward:

"mounts": [
  "source=${localEnv:SSH_HOME},target=/root/.ssh,type=bind,consistency=cached"
]

The problem is: I and every other developer needs to set up the $SSH_HOME env var on his machine, which pollutes the global env var space. For 99% of the time my OS is running, this env var isn’t needed. Additionally, I may have multiple VS Code instances running simultaneously, each requiring its own specific env var (with that identical name).

I'm looking for a way to use a placeholder in the source field that would be a valid entry to commit to Git. This could be either executable code (running a local script that computes a return value) or a mechanism to load specific variables (key/value pairs) from a file not checked into Git, which each dev sets up manually on his machine. While executable code is a potential solution, it might be challenging to create something that runs on both Linux and Windows.

Solutions I've already considered:

  1. Creating a local bash/PowerShell script that sets up the vars and then starts VS Code. The drawback is that I can't close and open other folders without exiting VS Code and running a new script in the shell.
  2. Using initializeCommand doesn't work. I can run a process that creates env vars, but they disappear as soon as the process ends.
  3. I created a plugin that sets process.env.SSH_HOME = '...', but this didn't work either. I even marked it in package.json as 'extensionKind': ['ui'] to ensure it runs when opening a devcontainer.

Is there a recommended approach to this issue that allows for flexible, developer-specific configuration without polluting the global environment or requiring constant manual intervention? Or should we consider adding a new feature to devcontainer.json for flexible, developer-specific configurations?

vs-code-engineering[bot] commented 1 month ago

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 10 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!