Test: process environment improvements

[bpasero]

Refs:

• macOS @chrmarti
• linux @weinand

Complexity: 4

Create Issue

---

Release Notes

On macOS and Linux, VSCode will spawn a unix shell in the background on startup to resolve the shell environment in case VSCode has not been started from a terminal already. We want to assign all shell environment variables into process.env so that the experience launching VSCode from the UI is no different from launching it from a terminal. E.g. any path related shell environment should work in both cases.

The downside of this approach is that we block the window from opening until this shell environment is resolved. We have #108804 already as issue to resolve that in the future.

During this milestone numerous changes to this feature have been made that need testing:

• add a sleep 4 as first line to your .bashrc or .zshrc file and open VSCode from the UI (e.g. dock), verify you see a warning notification with a link that guides you
• add a sleep 11 as first line to your .bashrc or .zshrc file and open VSCode from the UI (e.g. dock), verify you see a error notification with a link that guides you
• (make sure to have these changes undone again :)
• run VSCode from the UI and open a second instance from the terminal on a different folder but define a custom environment variable before starting (e.g. export FOO=BAR) and verify this environment variable ends up in that second window and even survives folder changes (you can verify by typing process.env in the devtools console of that second window)
• run VSCode from the UI and open a second instance from the terminal on a different folder but change an existing environment variable (e.g. PATH) before starting and verify this environment variable with your value ends up in that second window and even survives folder changes
• run VSCode from the terminal and open a second instance from the terminal on a different folder but define a custom environment variable before starting (e.g. export FOO=BAR) and verify this environment variable ends up in that second window and even survives folder changes
• run VSCode from the terminal and open a second instance from the terminal on a different folder but change an existing environment variable (e.g. PATH) before starting and verify this environment variable with your value ends up in that second window and even survives folder changes

Note: any subsequent window will always inherit the environment from the first launch. E.g. if you run the first instance from a terminal with custom environment defined, all other windows will inherit that. But subsequent launches can alter the environment.

[weinand]

In addition to the test cases from above I've verified that node.js managers (e.g. nvm or nvs) do work.
An "nvm use 12.13.1" in a terminal followed by "code-insiders ." makes that version of node.js available in the VS Code instance but nowhere else.

[bpasero]

@weinand thanks a lot, that is a great use case that I should probably put into the release notes 👍

[weinand]

Overall the propagation (and isolation) of env vars into VS Code instances works fine.
But for linux (Ubuntu 20.04) I'm not sure that "running a background shell" always results in the same set of env vars as in a terminal.