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
Env vars are not passed to the extension host as expected after 1.53 update #115794
Comments
Observed this issue affects only I got verbose logging by passing the
Full log```
In the log, the
The
Our tests failed because they got the system default PATH. I don't know why though. Our current temporary workaround is switch back to 1.52.1. |
I really could only find this as affecting the env resolution: dce22cf, from 1.52 to 1.53 @roblourens Let me know if you can't find anything related to your changes. |
Thanks! It's also likely that this is specific to our docker container or |
This is temporary to unblock our CI. Updates #1190 Updates microsoft/vscode#115794 Change-Id: Icc642d692688695c00763fda3525488e0febb9ec Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/289770 Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> TryBot-Result: kokoro <noreply+kokoro@google.com> Reviewed-by: Suzy Mueller <suzmue@golang.org> Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
This is temporary to unblock our CI. Updates #1190 Updates microsoft/vscode#115794 Change-Id: Icc642d692688695c00763fda3525488e0febb9ec Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/289770 Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> TryBot-Result: kokoro <noreply+kokoro@google.com> Reviewed-by: Suzy Mueller <suzmue@golang.org> Trust: Hyang-Ah Hana Kim <hyangah@gmail.com> (cherry picked from commit df04ba2) Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/289971 Reviewed-by: Rebecca Stambler <rstambler@golang.org>
If you start vscode with the flag Could you attach the same log from a run in 1.52? One possibility is that your container is affected by the same issue in https://github.com/github/codespaces/issues/1639, where previously this process of probing environment vars wouldn't have happened at all because we weren't able to look up the shell. Now in 1.53 we are able to. And your container probably has a bashrc or profile or something else that sets the PATH to this default without appending to it. |
Thanks a lot @roblourens. Our tests are now passing with the flag! Is this flag recommended though? If so, feel free to close this issue. We use the standard node docker and the user from the definition.
Here is the requested log from a run in 1.52.1 [main 2021-02-05T21:55:38.577Z] Starting VS Code [main 2021-02-05T21:55:38.578Z] from: /workspace/.vscode-test/vscode-1.52.1/VSCode-linux-x64/resources/app [main 2021-02-05T21:55:38.578Z] args: { [main 2021-02-05T21:55:38.582Z] Resolving machine identifier... [main 2021-02-05T21:55:38.631Z] Resolved machine identifier: XXX [main 2021-02-05T21:55:38.656Z] [storage :memory:] open(:memory:, retryOnBusy: true) [main 2021-02-05T21:55:38.660Z] lifecycle (main): phase changed (value: 2) [main 2021-02-05T21:55:38.661Z] windowsManager#open [main 2021-02-05T21:55:38.661Z] windowsManager#open pathsToOpen [ [Object: null prototype] {} ] [main 2021-02-05T21:55:38.663Z] window#validateWindowState: validating window state on 1 display(s) { [main 2021-02-05T21:55:38.663Z] window#validateWindowState: 1 monitor working area { x: 0, y: 0, width: 1024, height: 768 } [main 2021-02-05T21:55:38.663Z] window#ctor: using window state { [main 2021-02-05T21:55:38.721Z] windowsManager#open used window count 1 (workspacesToOpen: 0, foldersToOpen: 0, emptyToRestore: 0, emptyToOpen: 1) [main 2021-02-05T21:55:38.721Z] lifecycle (main): phase changed (value: 3) [main 2021-02-05T21:55:38.722Z] update#setState idle [main 2021-02-05T21:55:38.723Z] resolveShellEnv(): running (macOS/Linux) [main 2021-02-05T21:55:38.723Z] getUnixShellEnvironment#runAsNode undefined [main 2021-02-05T21:55:38.723Z] getUnixShellEnvironment#noAttach undefined [main 2021-02-05T21:55:38.723Z] getUnixShellEnvironment#env { [main 2021-02-05T21:55:38.724Z] getUnixShellEnvironment#spawn '/workspace/.vscode-test/vscode-1.52.1/VSCode-linux-x64/code' -p '"e2e3ba25ade9" + JSON.stringify(process.env) + "e2e3ba25ade9"' [main 2021-02-05T21:55:38.730Z] getUnixShellEnvironment#error The "file" argument must be of type string. Received type undefined [main 2021-02-05T21:55:38.737Z] [File Watcher (node.js)] [ADDED] /workspace/${workspaceFolder}/.user-data-dir-test/User/workspaceStorage [main 2021-02-05T21:55:38.739Z] [storage :memory:] Trace (event): SELECT * FROM ItemTable [main 2021-02-05T21:55:38.744Z] [storage :memory:] getItems(): 0 rows [main 2021-02-05T21:55:38.822Z] resolveShellEnv(): running (macOS/Linux) ... |
Thanks, the 1.52 log confirms what I suspected. Yes I think this flag would be the recommendation for when you are launching VS Code to inherit its environment instead of discovering a clean env from the user's shell configuration. It should give the exact same behavior as what you had in 1.52. |
As explained in microsoft/vscode#115794 (comment) VS Code 1.53 finds the shell and initializes the environment based on the users' bashrc or shell profile rather than simply inheriting the environments from the parent process. Our CI runs as the default user of the node docker container which has a shell environment (with the system default PATH). As a result, VS Code in test started to run with the system default PATH instead of the PATH we set from the container or the test runner script. Disable this VS Code's new behavior and let the test use the environment variables we set up for the test. Remove the temporary fix (https://golang.org/cl/289770). Fixes #1190 Change-Id: I84c0580237a3340025cb1e3f776c566841a4a0d2 Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/290370 Trust: Hyang-Ah Hana Kim <hyangah@gmail.com> Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> Reviewed-by: Suzy Mueller <suzmue@golang.org> TryBot-Result: kokoro <noreply+kokoro@google.com>
Our extension tests started to fail after 1.53 update because they couldn't find the tools the extension depends on from PATH any more. In our CI, we configure PATH to include the directory for those tools, and then run the test script that uses
'vscode-test'
'srunTests
. A bit of logging revealed that the test code no longer sees the PATH value we configured.The tests still pass with 1.52.1.
I cannot find the relevant change description from the release note yet.
Sorry if I missed related announcement.
I am not sure yet this change of behavior actually affects our extension users, or this is just a problem when running the test script that uses the
runTests
library.The text was updated successfully, but these errors were encountered: