Uh oh!
There was an error while loading. Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork 34.2k
test: pass process.env to child processes#16405
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
Uh oh!
There was an error while loading. Please reload this page.
Conversation
aa8ebe9 to e49fd4aComparegibfahn commented Oct 23, 2017
That was a month ago (#15557), so really looking forward to having this tested in CI. |
e49fd4a to 6078c6cComparervagg commented Oct 23, 2017
https://ci.nodejs.org/job/node-test-commit/13393/ ignore the lint failure there, I messed up some stuff in benchmark/_http-benchmarkers.js that I've force-pushed fixes for since submitting the job. |
rvagg commented Oct 23, 2017
@gibfahn I suspect we might find even more instances once we start testing zlib, cares and others as dynamic non-globals. |
cjihrig left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM with a question.
benchmark/_http-benchmarkers.js Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aren't the {env: process.env } changes unnecessary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cjihrig in theory yes, for -h in here you just want them to run, but I figured that we don't control how these applications execute and for all we know they are linked to (or load) crypto/openssl or some other dependency and might fail even for a simple -h. Imagine a custom build of wrk that's dynamically linked to a custom library and needs a path in LD_LIBRARY_PATH.
I could take these out but it seems appropriate to me to just inherit the environment in all of our external tool exec in the test suite.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I totally agree that the tools should inherit the environment. What I meant is that the environment is inherited by default, unless you set values for the env option, so {env: process.env } is redundant. I don't mind it either way.
Side note, and possibly a good first contribution: the child_process docs could do a better job pointing out that process.env is the default. Right now, you have to read a lot of text to see that. IMO, it should be part of the option description, like it is for most of the other options.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cjihrig gotcha, so I've gone overkill here and it's only the single fork() that needs the adjustment, will remove these, thanks for pointing this out
rvagg commented Oct 23, 2017
Failing across windows: This is related cause I changed this file. Something about the environment slipping in to cause DNS failures? I'm not sure about this one. |
PR-URL: nodejs#16405 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Gibson Fahnestock <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Gireesh Punathil <[email protected]>
6078c6c to edffa1dComparervagg commented Nov 9, 2017
fixed windows problem, it was the basic TestDouble benchmark that was using PTAL @cjihrig@refack@gireeshpunathil@gibfahn and I'll get this landed |
rvagg commented Nov 9, 2017
https://ci.nodejs.org/job/node-test-commit/13892/ FYI, see also the green ticks down below |
gibfahn left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still LGTM
cjihrig commented Nov 9, 2017
Still LGTM |
gireeshpunathil commented Nov 9, 2017
LGTM, thanks! |
rvagg commented Nov 9, 2017
landed in 3b3ceaf |
For variables such as LD_LIBRARY_PATH and DYLD_LIBRARY_PATH that are needed for dynamically linked binaries PR-URL: #16405 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Gibson Fahnestock <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Gireesh Punathil <[email protected]>
For variables such as LD_LIBRARY_PATH and DYLD_LIBRARY_PATH that are needed for dynamically linked binaries PR-URL: #16405 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Gibson Fahnestock <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Gireesh Punathil <[email protected]>
For variables such as LD_LIBRARY_PATH and DYLD_LIBRARY_PATH that are needed for dynamically linked binaries PR-URL: #16405 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Gibson Fahnestock <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Gireesh Punathil <[email protected]>
Primarily for testing when using
LD_LIBRARY_PATHandDYLD_LIBRARY_PATH, these are a few newer instances that have been added since someone last tried to do this. Found while testing OpenSSL 1.1.0 dynamic linking for #16130.Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passesAffected core subsystem(s)
test