Skip to content
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

Something appears to mess with PATH on Travis Linux when running tests #20

Open
DanTup opened this issue Apr 5, 2018 · 23 comments
Open

Comments

@DanTup
Copy link

DanTup commented Apr 5, 2018

I pushed a repo to Travis that is just the TypeScript extension sample with a travis file that echos the PATH in the Travis script, the npm test script and then also inside the sample test. The values are different. Significantly, the path to node has been removed by the time we get into the tests. In my real project, this means my tests are failing because they use the DebugClient and pass node as the executable.

Here's the code:
https://github.com/DanTup/vscode_extension_path_test

Here's the Travis log:
https://travis-ci.org/DanTup/vscode_extension_path_test/jobs/362281254

Here's the relevant parts:

PATH as output in the travis file:

./node_modules/.bin:/home/travis/bin:/home/travis/.local/bin:/opt/pyenv/shims:/home/travis/.phpenv/shims:/home/travis/perl5/perlbrew/bin:/home/travis/.nvm/versions/node/v8.11.1/bin:/home/travis/.kiex/elixirs/elixir-1.4.5/bin:/home/travis/.kiex/bin:/home/travis/.rvm/gems/ruby-2.4.1/bin:/home/travis/.rvm/gems/ruby-2.4.1@global/bin:/home/travis/.rvm/rubies/ruby-2.4.1/bin:/home/travis/gopath/bin:/usr/local/phantomjs/bin:/usr/local/phantomjs:/usr/local/neo4j-3.2.7/bin:/usr/local/maven-3.5.2/bin:/usr/local/cmake-3.9.2/bin:/usr/local/clang-5.0.0/bin:/home/travis/.gimme/versions/go1.7.4.linux.amd64/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/home/travis/.rvm/bin:/home/travis/.phpenv/bin:/opt/pyenv/bin:/home/travis/.yarn/bin

PATH as output by prefixing the test script in package.json with echo $PATH:

/home/travis/.nvm/versions/node/v8.11.1/lib/node_modules/npm/node_modules/npm-lifecycle/node-gyp-bin:/home/travis/build/DanTup/vscode_extension_path_test/node_modules/.bin:./node_modules/.bin:/home/travis/bin:/home/travis/.local/bin:/opt/pyenv/shims:/home/travis/.phpenv/shims:/home/travis/perl5/perlbrew/bin:/home/travis/.nvm/versions/node/v8.11.1/bin:/home/travis/.kiex/elixirs/elixir-1.4.5/bin:/home/travis/.kiex/bin:/home/travis/.rvm/gems/ruby-2.4.1/bin:/home/travis/.rvm/gems/ruby-2.4.1@global/bin:/home/travis/.rvm/rubies/ruby-2.4.1/bin:/home/travis/gopath/bin:/usr/local/phantomjs/bin:/usr/local/phantomjs:/usr/local/neo4j-3.2.7/bin:/usr/local/maven-3.5.2/bin:/usr/local/cmake-3.9.2/bin:/usr/local/clang-5.0.0/bin:/home/travis/.gimme/versions/go1.7.4.linux.amd64/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/home/travis/.rvm/bin:/home/travis/.phpenv/bin:/opt/pyenv/bin:/home/travis/.yarn/bin

PATH as output in tests:

/home/travis/.local/bin:/opt/pyenv/shims:/home/travis/.phpenv/shims:/home/travis/perl5/perlbrew/bin:/home/travis/.kiex/elixirs/elixir-1.4.5/bin:/home/travis/.kiex/bin:/home/travis/.phpenv/shims:/home/travis/gopath/bin:/home/travis/.gimme/versions/go1.7.4.linux.amd64/bin:/usr/local/phantomjs/bin:/usr/local/phantomjs:/usr/local/neo4j-3.2.7/bin:/usr/local/maven-3.5.2/bin:/usr/local/cmake-3.9.2/bin:/usr/local/clang-5.0.0/bin:/home/travis/.gimme/versions/go1.7.4.linux.amd64/bin:/usr/local/phantomjs/bin:/usr/local/phantomjs:/usr/local/neo4j-3.2.7/bin:/usr/local/maven-3.5.2/bin:/usr/local/cmake-3.9.2/bin:/usr/local/clang-5.0.0/bin:/home/travis/.nvm/versions/node/v8.11.1/lib/node_modules/npm/node_modules/npm-lifecycle/node-gyp-bin:/home/travis/build/DanTup/vscode_extension_path_test/node_modules/.bin:./node_modules/.bin:/home/travis/bin:/home/travis/.local/bin:/opt/pyenv/shims:/home/travis/.phpenv/shims:/home/travis/.kiex/elixirs/elixir-1.4.5/bin:/home/travis/.kiex/bin:/home/travis/.rvm/gems/ruby-2.4.1/bin:/home/travis/.rvm/gems/ruby-2.4.1@global/bin:/home/travis/.rvm/rubies/ruby-2.4.1/bin:/home/travis/gopath/bin:/usr/local/phantomjs/bin:/usr/local/phantomjs:/usr/local/neo4j-3.2.7/bin:/usr/local/maven-3.5.2/bin:/usr/local/cmake-3.9.2/bin:/usr/local/clang-5.0.0/bin:/home/travis/.gimme/versions/go1.7.4.linux.amd64/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/home/travis/.rvm/bin:/home/travis/.phpenv/bin:/opt/pyenv/bin:/home/travis/.yarn/bin:/home/travis/.phpenv/bin:/opt/pyenv/bin

Note that /home/travis/.nvm/versions/node/v8.11.1/bin exists in the first and second, but not the last one (the one from inside the tests).

DanTup referenced this issue in Dart-Code/Dart-Code Apr 5, 2018
@DanTup
Copy link
Author

DanTup commented Apr 5, 2018

As a workaround, since I only need to spawn nodejs, I'm just passing process.execPath instead of "node" to the DebugClient.

DanTup referenced this issue in Dart-Code/Dart-Code Apr 5, 2018
DanTup referenced this issue in Dart-Code/Dart-Code Apr 5, 2018
DanTup referenced this issue in Dart-Code/Dart-Code Apr 5, 2018
DanTup referenced this issue in Dart-Code/Dart-Code Apr 5, 2018
DanTup referenced this issue in Dart-Code/Dart-Code Apr 5, 2018
@bpasero bpasero self-assigned this Apr 6, 2018
DanTup referenced this issue in Dart-Code/Dart-Code Apr 16, 2018
@bpasero
Copy link
Member

bpasero commented May 29, 2019

@bpasero bpasero closed this as completed May 29, 2019
@DanTup
Copy link
Author

DanTup commented May 29, 2019

Will do!

BTW, it seems like both those new packages exist - is there anything stopping me migrating now? (I'm not sure what needs to land).

Thanks!

@bpasero
Copy link
Member

bpasero commented May 29, 2019

@octref can maybe comment who is in charge of these new packages

@octref
Copy link
Contributor

octref commented May 29, 2019

Go ahead and let me know issues you run into.

@DanTup
Copy link
Author

DanTup commented Jun 5, 2019

@octref I noticed the info linked above has all been removed from the release notes:

microsoft/vscode-docs@9402e03#diff-0ae46b9ea8531a6a66fe2ed2a836709a

Does this mean it's not safe to go ahead with migrating?

@DanTup
Copy link
Author

DanTup commented Jun 5, 2019

Scratch that, it seems to be working, so I've gone with it (though I'm curious why it was removed from release notes).

@bpasero the original issue here is still present on latest versions of everything and using that package.

It actually somewhat repros locally.. If I run npm run test using the repo I linked above, the PATH is different inside the tests to out. If you run npm run test it prints path before running the tests, because the definition of the test script in package.json is this:

 "test": "echo $PATH && npm run compile && node ./out/test/runTest.js"

Inside the test, I have this:

        console.log("INSIDE TESTS, PATH IS");
        console.log(process.env.PATH);

And the output of the two differs. Inside the test the first three items have been added to the end of PATH and the first two of them removed from the beginning (in this case nothing is lost, but the ordering has changed which is still bad):

Screenshot 2019-06-05 at 9 42 14 am

Running on Travis Linux, some items are added to the beginning and end, and two items are removed from the middle (one of them is added to the beginning, so possibly removed to be de-duped, but the other is node - the same thing originally reported above):

Screenshot 2019-06-05 at 9 50 40 am

@DanTup
Copy link
Author

DanTup commented Jun 5, 2019

@bpasero
Copy link
Member

bpasero commented Jun 5, 2019

PR welcome, I will not have time to look into this.

@bpasero bpasero reopened this Jun 5, 2019
@bpasero
Copy link
Member

bpasero commented Jun 5, 2019

@octref please decide if this should move into the vscode-test repository.

@DanTup
Copy link
Author

DanTup commented Jun 5, 2019

I'm not sure I'd know where to start looking - I can't come up with any explanation for what might be happening 🤷‍♂️

It's not critical, I've worked around it by just setting another env variable and then reading from it in the extension, but it's a little weird 🙃

@bpasero
Copy link
Member

bpasero commented Jun 5, 2019

Ok good to know there is a workaround. We can close this issue if no-one jumps on it in the next weeks.

@octref octref transferred this issue from microsoft/vscode-extension-vscode Jun 17, 2019
@octref octref added this to the June 2019 milestone Jun 17, 2019
@octref
Copy link
Contributor

octref commented Jun 17, 2019

vscode-test reads from process.env and add any testRunnerEnv if specified:

https://github.com/microsoft/vscode-test/blob/master/lib/runTest.ts#L159-L160

I'm not sure if it's a Travis problem (maybe try Azure Devops?) or npm script limiting the $PATH for it scripts. Can you try cross-env too?

@DanTup
Copy link
Author

DanTup commented Jun 19, 2019

Ok, this is easily reproducible on macOS locally, so it's not Linux specific or Travis specific.

If I mess with my path (eg., push cwd onto the front export PATH=`pwd`:$PATH) and then run code . then the path is correct:

[16:06:57] [General] [Info] Environment PATH:
[16:06:57] [General] [Info]     /Users/dantup/Dev/vscode-repros/vscode_extension_path_test <!--
[16:06:57] [General] [Info]     /Users/dantup/Dev/homebrew/bin
[16:06:57] [General] [Info]     /usr/local/git/current/bin
[16:06:57] [General] [Info]     /usr/local/bin
<snip>
[16:06:57] [General] [Info]     ~/.dotnet/tools
[16:06:57] [General] [Info]     /Users/dantup/.npm-global/bin/

But if I run the way the test runner does (though I've removed the extension/test path since that makes no differences to the outcome):

"/Users/dantup/Dev/vscode-repros/vscode_extension_path_test/.vscode-test/vscode-1.35.1/Visual Studio Code.app/Contents/MacOS/Electron" .

The path is messed up:

[16:07:35] [General] [Info] Environment PATH:
[16:07:35] [General] [Info]     /Users/dantup/Dev/homebrew/bin
[16:07:35] [General] [Info]     /usr/local/git/current/bin
[16:07:35] [General] [Info]     /usr/local/bin
<snip>
[16:07:35] [General] [Info]     ~/.dotnet/tools
[16:07:35] [General] [Info]     /Users/dantup/.npm-global/bin/
[16:07:35] [General] [Info]     /Users/dantup/Dev/vscode-repros/vscode_extension_path_test <-- !!
[16:07:35] [General] [Info]     /Users/dantup/Dev/homebrew/bin

Note that the entry I added is now near the end.

@octref octref modified the milestones: June 2019, July 2019 Jul 24, 2019
@octref octref modified the milestones: July 2019, August 2019 Aug 6, 2019
@octref octref modified the milestones: August 2019, November 2019 Nov 20, 2019
@disposedtrolley
Copy link

disposedtrolley commented Nov 21, 2019

I think I'm getting bitten by this one and would love some advice if possible!

I'm trying to test an extension which spins up a language server via the Executable method upon activation. The executable is an NPM module installed globally and available on the PATH.

During testing the extension fails to start the language server and reports an ENOENT error which I assume is because the executable can't be located on the PATH. I've tried passing through the entirety of process.env when I call runTests() to no avail:

await runTests({
  extensionDevelopmentPath,
  extensionTestsPath,
  extensionTestsEnv: process.env,
  launchArgs: [extensionWorkspacePath, "--disable-extensions"]
});

I'm trying to run the tests on macOS 10.14 locally, and 10.13 on Travis.

@DanTup
Copy link
Author

DanTup commented Nov 21, 2019

I never really got to the bottom of it. I think it may be node/npm messing with the path. My workaround was to use the full path to node when spawning my debug adapter (see Dart-Code/Dart-Code@e4b6fb0) instead of just "node" so it doesn't look in PATH and therefore doesn't get the wrong version. The PATH is still a bit messed up, but it's not being used to resolve anything that has multiple versions anymore so it doesn't cause a problem.

@disposedtrolley
Copy link

Ahh I see, thanks for the quick response!

I might be able to make that work for testing, but since the language server executable is installed separately by the user, we'd have no control over the actual location of the binary so would need to rely on PATH resolution. I've opened up a new ticket #52 if you're interested in following along!

Meanwhile I might do some more digging to see whether node or NPM are the culprits.

@DanTup
Copy link
Author

DanTup commented Nov 21, 2019

Ah, my fix above only really fixed the ordering (where there were two different node versions).

I did for a while (though I can't remmeber if it was because of this) put my paths into custom env variables, and then updated my extension to scan those locations before PATH.

@disposedtrolley
Copy link

Oh ok. I think the problem I'm having is that none of the environment variables are being passed through to the test scripts. Even if I explicitly set some random variables, process.env is blank in the test script.

@jdneo
Copy link
Member

jdneo commented Nov 22, 2019

Having the same problem. Before calling runTests({}), the environment variable is correct. But when test session is launched, it seems not picking up those envs although I have passed them in extensionTestsEnv

@disposedtrolley
Copy link

I managed to get it working! My findings are here - #52 (comment)

@jdneo
Copy link
Member

jdneo commented Nov 22, 2019

Thank you @disposedtrolley,

Yes I just noticed you comment and had a try but still not able to workaround it. Not sure why. Maybe I'm using vscode-test@1.2.0?

@octref
Copy link
Contributor

octref commented Dec 11, 2019

it seems not picking up those envs although I have passed them in extensionTestsEnv

They are passed to cp.spawn. You can do this to see what's happening:

I pushed a branch:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants
@bpasero @DanTup @octref @disposedtrolley @jdneo and others