Uh oh!
There was an error while loading. Please reload this page.
test: pass process.env to child processes - #16405
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. |
There was a problem hiding this comment.
Aren't the { env: process.env } changes unnecessary?
There was a problem hiding this comment.
@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.
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.
@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 <refack@gmail.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
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 |
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 <refack@gmail.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
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 <refack@gmail.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
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 <refack@gmail.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
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