Previously for each matching test, it would execute multiple
`node -p` commands to decide the configurations of the executable.
That means if there are 100 tests matched, it will run the Node.js
executable 4*100 times to retrieve the same configurations repeatedly.
This changes the loop order so that it only execute these commands
once and reuse the results for all matching tests.
PR-URL: https://github.com/nodejs/node/pull/60266
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Previously, selecting subsystems with numbers in their names, like
http2, weren't matched due to a restrictive regex:
```
$ tools/test.py http2
No tests to run.
```
The regex now allows digits, so these tests run as expected:
```
$ tools/test.py http2
[00:17|% 100|+ 286|- 0]: Done
All tests passed.
```
Signed-off-by: Darshan Sen <raisinten@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/59242
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
The output of `node -p process.config.variables.asan` includes
a newline character so it's never exactly "1", which means
asan is always "off" for the status files. This fixes the
detection by stripping whitespaces from the output.
PR-URL: https://github.com/nodejs/node/pull/52766
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
We run all WPT from one subset in the same process using workers.
As the number of the tests grow, it can take longer to run some of the
subsets, but it's still overall faster than running them in different
processes. This patch increases the timeout
for WPT to prevent the test from failing because it takes longer
to run (even though it would still complete at some point).
PR-URL: https://github.com/nodejs/node/pull/44574
Refs: https://github.com/nodejs/reliability/issues/371
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
test-benchmark-buffer is consistently timing out on a single Windows
host in CI. Rather than try to figure out if we need to scale the
timeout up for a certain memory limit or chip speed or something else,
let's increase the timeout for benchmark tests in general.
PR-URL: https://github.com/nodejs/node/pull/40684
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Voltrex <mohammadkeyvanzade94@gmail.com>
`output.diagnostic` is a list that is appended to on SmartOS when
retrying a test due to `ECONNREFUSED`. The test runner checks if
`output.diagnostic` is truthy and, if so, assigns its value to
`self.traceback`. However `self.traceback` is supposed to be a string,
and `_printDiagnostic()` in the `TapProgressIndicator` attempts to call
`splitlines()` on it, which fails if it is a list with:
AttributeError: 'list' object has no attribute 'splitlines'
PR-URL: https://github.com/nodejs/node/pull/38289
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Christian Clauss <cclauss@me.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
It's possible to annotate failures in Actions by printing
"::error file={},line={},col={}::{message}". This methos is preferrable
over using a problem matcher because problem matchers only allow
single-line messages, whereas ::error allows multi-line messages.
PR-URL: https://github.com/nodejs/node/pull/34590
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
This fixes the following crash on Windows for me. I don't know
why this I only started to see this now, but anyway, the new timeout
value is still longer than a week and a half.
File "tools/test.py", line 1725, in <module>
sys.exit(Main())
File "tools/test.py", line 1701, in Main
if RunTestCases(cases_to_run, options.progress, \
options.j, options.flaky_tests):
File "tools/test.py", line 923, in RunTestCases
return progress.Run(tasks)
File "tools/test.py", line 145, in Run
thread.join(timeout=10000000)
File "C:\Users\anna\AppData\Local\Programs\Python\Python38-32\ \
lib\threading.py", line 1015, in join
self._wait_for_tstate_lock(timeout=max(timeout, 0))
File "C:\Users\anna\AppData\Local\Programs\Python\Python38-32\ \
lib\threading.py", line 1027, in _wait_for_tstate_lock
elif lock.acquire(block, timeout):
OverflowError: timeout value is too large
PR-URL: https://github.com/nodejs/node/pull/32868
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Zeyu Yang <himself65@outlook.com>
Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
A logfile must be opened as a text file and encoding is specified.
Then it can accept a string. Current behaviour we get,
Message: 'ok 2834 sequential/test-worker-prof'
Arguments: ()
--- Logging error ---
Traceback (most recent call last):
File "/usr/lib64/python3.7/logging/__init__.py", line 1037, in emit
stream.write(msg + self.terminator)
TypeError: a bytes-like object is required, not 'str'
Call stack:
File "tools/test.py", line 1734, in <module>
sys.exit(Main())
File "tools/test.py", line 1710, in Main
if RunTestCases(cases_to_run, options.progress, options.j, options.flaky_tests):
File "tools/test.py", line 933, in RunTestCases
return progress.Run(tasks)
File "tools/test.py", line 141, in Run
self.RunSingle(False, 0)
File "tools/test.py", line 202, in RunSingle
self.HasRun(output)
File "tools/test.py", line 365, in HasRun
logger.info(' ---')
PR-URL: https://github.com/nodejs/node/pull/31156
Reviewed-By: Christian Clauss <cclauss@me.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: David Carlier <devnexen@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Daijiro Wachi <daijiro.wachi@gmail.com>
