test: pass env through to child processes #14845
Conversation
|
Well I guess even that is already very useful. |
|
I would say that @vsemozhetbyt 's syntax in #14823 (comment) looks really neat, it's a pity we can't start using it for a while. child_process.exec(cmd, { env: { ...process.env, NEW_VAR: 1 } }); |
|
As for the debate: |
test/common/README.md
Outdated
| ### envPlus(additionalEnv) | ||
| * return [<Object>] | ||
|
|
||
| Returns `process.env` plus `additionalEnv`. Used to pass a temporarily modified |
There was a problem hiding this comment.
I think the word temporarily is misguiding here. The environment of the child process is modified for its entire lifetime, and the enviroment of the calling process is left unchanged.
test/parallel/test-crypto-fips.js
Outdated
| @@ -72,7 +63,7 @@ testHelper( | |||
| [], | |||
| FIPS_DISABLED, | |||
| 'require("crypto").fips', | |||
| addToEnv('OPENSSL_CONF', '')); | |||
| common.envPlus({ 'OPENSSL_CONF': '' })); | |||
There was a problem hiding this comment.
You could as well drop the quotes here and below.
There was a problem hiding this comment.
This changes a bunch of tests from passing bare environments with just one or two variables set to passing robust environments that inherit tons of environment variables.
This potentially introduces vectors for failing tests, especially in people's local environments. (I suppose it also may fix local tests for some people. But do we have reason to believe this is a significant problem? Honest question, I have no idea.) I don't think those tests should be altered to include user-set environment variables unless there is a compelling reason.
For tests that already have code that duplicates the environment, sure this should not be an issue. But it's all those other cases that are modified here that make me uncomfortable.
|
Refs: recently landed #14822 |
|
@Trott you're right, but not having the local environment can also cause problems. The two I've noticed recently are Basically we either have a blacklist or a whitelist. The nice thing about a I'd rather have a blacklist (if necessary) than a whitelist, but open to suggestions.
Sure, but the reason those shouldn't be an issue isn't because of something about the tests themselves, it's just because they've been out in the wild for a while, so we'd hope people have run into any issues. |
@Trott question IMHO actually strengthens the need for an abstracted environment-cloning method (over |
Add a helper function to provide an easy way to modify the environment passed to child processes. Fixes: nodejs#14823
I don't see the need right now, but maybe, if there's something that you think should be abstracted. I think the spawns in tests get called with a lot of different configurations, so I'm not sure whether it would be worth it. Basically (for me) with common functions, there has to be enough of a reason to use them to outweigh having to remember them and look them up. That means it has to be easier to use the function than to reimplement it. I was on the fence about this function before, the idea of being able to control blacklists or whitelists makes it a no-brainer for me. IDK about |
I just have an intuition. I'll do an audit. |
Trott
dismissed
their stale review
I'm almost never a fan of adding another abstraction that only exists in common.js for people to have to learn to use. But people have clearly thought about this, so I'm dismissing my request for changes.
|
I think it would be much better to just use Object.assign directly if necessary and not to add another common function. These functions increase the difficulty for everyone new and if they do not bring much benefit I am against adding them. Another negative point is that you can also not just copy a single test case into the repl with common syntax and this is often a fast way to test a special case in a big test file. A plain JS version is therefore always preferred by me and I would rather not land this. |
As I said earlier, I'm not completely sold on this either. As it stands this just unifies the syntax and stops tests breaking because they don't pass down the existing environment to child processes. However if we need to blacklist/whitelist environment variables that cause problems with people's tests going forward, then having this function will be necessary.
Does that work often? You can just paste the middle of a test in without needing the initial setup/require stuff? In any case, pasting the FWIW, of the 1547 tests in |
|
It depends on the test if it works or not. I just did that a couple of times for small tests. It works fine for those most of the time as they often do not have any further requirements (and common is not always required for a test even if it is required in the test file). |
Sure, that was my point about the 1151 (have requirements) vs 396 (don't). It's required if it's declared with |
|
@gibfahn I am not sure if we are talking about the same thing but it was not a important point for me anyway. Nevertheless I am still not a fan and I would rather not land this but I will also not stand in the way if other push for it. |
|
Went back through the tests again, and I tend to agree that the mental complexity of adding another helper method isn't worth it for this, so I've removed it, PTAL. |
gibfahn
changed the title
Of what? As I've removed the |
|
I simply don't have a strong opinion on passing the environment around, mainly because I personally did not have any issues not doing that, but I understand the associated problems. I still think @Trott has a point (referring to his first review), but we can think about that once problems arise (if ever). No discussion necessary, as I said, the changes LGTM. |
|
I believe @Trott may be taking a bit of personal time this week so might need to give him another day or two to respond. |
|
Well as we already pass through the env to a lot of tests I guess it does not change a lot to do that with the other ones as well. If someone runs into issues we have to think about a new solution anyway. So I withdraw my last concerns and I am OK with landing this as is. |
|
Landed in 180f865 |
PR-URL: #14845 Fixes: #14823 Refs: #14822 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Yuta Hiroto <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Rich Trott <[email protected]>
|
@BridgeAR thanks for landing. For posterity the commit message looks a bit odd, as it says |
|
@gibfahn uh, you are right. My bad. |
PR-URL: nodejs/node#14845 Fixes: nodejs/node#14823 Refs: nodejs/node#14822 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Yuta Hiroto <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Rich Trott <[email protected]>
PR-URL: #14845 Fixes: #14823 Refs: #14822 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Yuta Hiroto <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Rich Trott <[email protected]>
PR-URL: #14845 Fixes: #14823 Refs: #14822 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Yuta Hiroto <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Rich Trott <[email protected]>
PR-URL: #14845 Fixes: #14823 Refs: #14822 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Yuta Hiroto <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Rich Trott <[email protected]>
|
Should this be backported to |
|
Backport in #15557 |
PR-URL: nodejs#14845 Backport-PR-URL: nodejs#15557 Fixes: nodejs#14823 Refs: nodejs#14822 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Yuta Hiroto <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Rich Trott <[email protected]>
PR-URL: #14845 Backport-PR-URL: #15557 Fixes: #14823 Refs: #14822 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Yuta Hiroto <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Rich Trott <[email protected]>
PR-URL: #14845 Backport-PR-URL: #15557 Fixes: #14823 Refs: #14822 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Yuta Hiroto <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Rich Trott <[email protected]>
Add a helper function to provide an easy way to modify the
environment passed to child processes.
Fixes: #14823
Refs: #14822
The function itself is trivial, the main benefit to having it is that it gives an easy way to pass modified environments to child processes. There are a bunch of tests that don't pass the environment through to child processes, and the tests that do use a variety of methods. So ideally by having a
commonfunction we can standardise on this way of doing things.An alternative would be to just replace all of these with
Object.assign({}, process.env, additionalEnv).Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passesAffected core subsystem(s)
test