-
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, build: add test-ci wrappers #12874
Conversation
/cc @nodejs/build @nodejs/python |
tools/test-ci.sh
Outdated
@@ -0,0 +1,3 @@ | |||
pushd `dirname $0`/.. > /dev/null |
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.
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).
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.
Done
tools/test-ci.sh
Outdated
@@ -0,0 +1,3 @@ | |||
pushd `dirname $0`/.. > /dev/null | |||
`which python` tools/test.py -J --mode=release $* |
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Read, and found the way, thanks
|
||
test-valgrind: all | ||
$(PYTHON) tools/test.py --mode=release --valgrind sequential parallel message | ||
|
||
test-check-deopts: all | ||
$(PYTHON) tools/test.py --mode=release --check-deopts parallel sequential -J | ||
$(TEST_CI) --check-deopts parallel sequential |
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 have to admit I don’t quite get what the goal of these changes is?
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.
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
|
||
:exit | ||
if not defined DISTTYPEDIR $DISTTYPEDIR=%DISTTYPE% | ||
goto :EOF |
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.
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 |
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if [ -z "$PYTHON" ]
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.
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 🤷♀️
tools/test-ci.cmd
Outdated
@@ -0,0 +1,3 @@ | |||
pushd %~dp0\.. | |||
python tools\test.py -J --mode=release %* | |||
popd |
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.
just curious, does the Windows cmd
actually require this?
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.
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 $* |
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.
"$PYTHON"
or "${PYTHON}"
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.... |
@@ -12,6 +12,7 @@ LOGLEVEL ?= silent | |||
OSTYPE := $(shell uname -s | tr '[A-Z]' '[a-z]') | |||
COVTESTS ?= test | |||
GTEST_FILTER ?= "*" | |||
export PYTHON |
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From what I read in the Makefile
man it is only "exported" to subshells, no the caller.
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.
Verified. It does not leak.
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.
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 |
@@ -43,6 +44,7 @@ NODE_EXE = node$(EXEEXT) | |||
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you made this something like:
TEST_CI = tools/test.py --mode=release -J
then wouldn't you get the same deduplication without the indirection of a separate file?
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
ninja
with onenode.ninja
for all ✊
SGTM
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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=1024
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.
@refack git
is not a requirement for testing, tho
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.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@addaleax for the whole concept?
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#!/usr/bin/env bash
would be more portable, right?
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.
Yep. But here it should be #!/bin/sh
anyway, not bash.
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.
does sh
have if [ -z
?
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.
Yes.
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.
ack
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
Makefile
whether it's safe as it bypasses the PYTHON var inconfig.mk
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)