-
Notifications
You must be signed in to change notification settings - Fork 30.1k
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
test: pass process.env to child processes #16405
Conversation
aa8ebe9
to
e49fd4a
Compare
That was a month ago (#15557), so really looking forward to having this tested in CI. |
e49fd4a
to
6078c6c
Compare
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. |
@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.
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
@@ -15,7 +15,8 @@ class AutocannonBenchmarker { | |||
this.name = 'autocannon'; | |||
this.executable = | |||
process.platform === 'win32' ? 'autocannon.cmd' : 'autocannon'; | |||
const result = child_process.spawnSync(this.executable, ['-h']); | |||
const result = | |||
child_process.spawnSync(this.executable, ['-h'], { env: process.env }); |
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
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
edffa1d
Compare
fixed windows problem, it was the basic TestDouble benchmark that was using PTAL @cjihrig @refack @gireeshpunathil @gibfahn and I'll get this landed |
https://ci.nodejs.org/job/node-test-commit/13892/ FYI, see also the green ticks down below |
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
Still LGTM |
LGTM, thanks! |
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_PATH
andDYLD_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