Conversation
|
/cc @nodejs/build @nodejs/python |
tools/test-ci.sh
Outdated
There was a problem hiding this comment.
Please add a shebang line at the top of this file.
Also, just use cd, pushd isn’t a common feature of all POSIX shells (and there’s no need to do the redirect).
tools/test-ci.sh
Outdated
There was a problem hiding this comment.
Regarding your question in the PR description, you may want to look into using $PYTHON here (and possible exporting that in the Makefile beforehand, I’m not sure)
There was a problem hiding this comment.
Read, and found the way, thanks
Makefile
Outdated
There was a problem hiding this comment.
I have to admit I don’t quite get what the goal of these changes is?
There was a problem hiding this comment.
Standardizing the calls to python tools\test.py
I admit that I'm not sure of the benefit of the changes in Makefile, especially if there is risk of breakage
vcbuild.ps1
Outdated
There was a problem hiding this comment.
Can I suggest adding this file in a second commit (or PR)? The changes don’t seem related?
* Replace explicit use in `Makefile` and `vcbuild.bat`
|
@addaleax the |
addaleax
left a comment
There was a problem hiding this comment.
This only seems to add abstraction that we don’t really need, so I’m -0 on it
tools/test-ci.sh
Outdated
| @@ -0,0 +1,4 @@ | |||
| #!/bin/bash | |||
| cd `dirname $0`/.. > /dev/null | |||
| if [ -z ${PYTHON+x} ]; then export PYTHON=`which python`; fi | |||
There was a problem hiding this comment.
There was a problem hiding this comment.
Yes, but I think setting PYTHON='' should give the default behaviour. Also, setting PYTHON=python in the then case here should be just fine.
There was a problem hiding this comment.
PYTHON=`which python` is for me, when running in WSL (Windows System for Linux) there's a bad behaviour where it'll try to run the windows python over the Ubuntu one 🤷♀️
| @@ -0,0 +1,3 @@ | |||
| pushd %~dp0\.. | |||
| python tools\test.py -J --mode=release %* | |||
| popd | |||
There was a problem hiding this comment.
just curious, does the Windows cmd actually require this?
There was a problem hiding this comment.
yes, it doesn't spawn a subshell so it cd the caller
tools/test-ci.sh
Outdated
| #!/bin/bash | ||
| cd `dirname $0`/.. > /dev/null | ||
| if [ -z ${PYTHON+x} ]; then export PYTHON=`which python`; fi | ||
| ${PYTHON} tools/test.py -J --mode=release $* |
|
I think I'm -1 on this. I'd rather not have command line arguments hidden. This would require you to go and look at the contents of the script to see what's currently being passed if you run into unexpected behavior, etc. |
|
One more thing I just noticed: The wrapper scripts don’t forward errors from the test runner properly |
you mean ERRORLEVEL / exit code? |
I agree it's a mixed bag... Something to think about.... |
| OSTYPE := $(shell uname -s | tr '[A-Z]' '[a-z]') | ||
| COVTESTS ?= test | ||
| GTEST_FILTER ?= "*" | ||
| export PYTHON |
There was a problem hiding this comment.
Is it necessary to export it? Modifying environment variables as a side effect of make may be an unexpected behavior. I'd rather require users to either export it explicitly or prepend each command with PYTHON=....
There was a problem hiding this comment.
From what I read in the Makefile man it is only "exported" to subshells, no the caller.
There was a problem hiding this comment.
Verified. It does not leak.
There was a problem hiding this comment.
Ah, okay. If that's the case, then fine.
|
To continue from #12830 (comment)
I get the problem that this is trying to solve, but I think the downside of adding an extra level of indirection (and another file that people have to know about) outweighs the benefit of having a standard way to run things, especially as the CI runs The windows build sounds like a problem, and I think it's definitely one we should look at. Does it still rebuild if you do On another note if you've got a WIP version of |
Actually I kind of started liking this, since it's self documenting code: "How does the CI call But If this gets -1 votes, I have no problem shelving it. Although I'd ask you all to think about it some more, less then as "another tool" but more as "refactoring out" all those same calls from the files I touched. @gibfahn as for the WIP |
| NODE ?= ./$(NODE_EXE) | ||
| NODE_G_EXE = node_g$(EXEEXT) | ||
| NPM ?= ./deps/npm/bin/npm-cli.js | ||
| TEST_CI = ./tools/test-ci.sh |
There was a problem hiding this comment.
If you made this something like:
TEST_CI = tools/test.py --mode=release -Jthen wouldn't you get the same deduplication without the indirection of a separate file?
There was a problem hiding this comment.
But what about vcbuild.bat and the case of #12830 & #12771
I was actually thinking of refactoring ALL the similar cases into tools/make to help alleviate #12425
But on the other hand Makefile can almost be read like a configuration file...
Anyway we should all move to ninja with one node.ninja for all ✊
There was a problem hiding this comment.
I'm pretty sure --mode=release is the default, so if we made -J the default as well then we definitely wouldn't need this indirection.
But what about
vcbuild.bat
This doesn't help with that though, you still have the tools/test.py command duplicated in Windows and Unix files.
I think people should run tools/test.py directly, this discourages them from doing that.
Anyway we should all move to
ninjawith onenode.ninjafor all ✊
SGTM
There was a problem hiding this comment.
But on the other hand Makefile can almost be read like a configuration file...
What about creating a mechanism with an explicit configuration file, that all script derive from...
(could be a Template filled by GYP)
something like:
test-cl:
"${PYTHON}" tools/test.py -J --mode=release $*
test-seq:
"${PYTHON}" tools/test.py --mode=release $*
test-deopt:
${test-cl} --check-deopts $*There was a problem hiding this comment.
Or hooking it into git (since it's already a requirement, and is platform uniform), then we could do
$ git tool test-cl parallel/test-stream2-transform
$ git tool lint
$ git tool benchmark buffers/buffer-tostring.js len=1024There was a problem hiding this comment.
@refack git is not a requirement for testing, tho
so a dual runner, git tool and node tool. One for bootstrapping, one for post-build tooling.
Could even throw in a python tool for the extreme minimalists...
There was a problem hiding this comment.
Yeah, I don’t think we should duplicate the same functionality over 2 or even 3 implementations.
If you want honest advice: Close this PR, or at least let it rest until you find somebody that thinks this is a good idea. Multiple people here have expressed doubt about the usefulness of this, and in a consensus-seeking model that’s a sign that it’s just not going to happen. And so the chances are, the more work you put into this, the more frustrated you’re going to be when the PR just stalls and doesn’t go anywhere.
There was a problem hiding this comment.
If you want honest advice: Close this PR
Yeah I've already put it on the back burner #12874 (comment)
Just kicking around the idea...
| @@ -0,0 +1,5 @@ | |||
| #!/bin/bash | |||
There was a problem hiding this comment.
#!/usr/bin/env bashwould be more portable, right?
There was a problem hiding this comment.
Yep. But here it should be #!/bin/sh anyway, not bash.
There was a problem hiding this comment.
does sh have if [ -z?
|
Not really need |
Ref: #12830 (comment)
Fixes: #12771
Added scripts that use the same args as the CI for use with single files or suites
Need help reviewing the change in
Makefilewhether it's safe as it bypasses the PYTHON var inconfig.mkChecklist
make -j4 test(UNIX), orvcbuild test(Windows) passesAffected core subsystem(s)