-
Notifications
You must be signed in to change notification settings - Fork 29.7k
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
tools,test: teach test.py new tricks #23251
Conversation
92bae01
to
323234e
Compare
@@ -0,0 +1,190 @@ | |||
[$mode==debug] |
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'd rather keep the test status in the respective .status
files in the test directories (e.g. parallel.status
).
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.
How strongly do you feel about that? IMHO having it in one place (1) will enabled easier auditing of this list (2) expresses that it's a cross-cutting concern.
I could instead move all the other rules to this single place, that also has benefits.
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.
Not that strongly 😆.
I could instead move all the other rules to this single place, that also has benefits.
I could get behind this. My worry is that at some point other annotations (e.g. flaky
) start appearing in root.status
in addition to e.g. parallel.status
(where they currently are set) and I'd rather avoid any potential confusion.
What do @nodejs/testing think?
Just to clarify: This only affects test in debug mode, and only when run in CI, and we still run the full suite in debug mode every day? If yes, 👍 good idea! Also, could you maybe write down what metric you used to tell slow tests apart? We’d probably want to move them off the list if we improve their performance. |
yes.
I'll verify.
Yes.
I copied an (arbitrary) test result to a spreadsheet, and selected all tests that took > 10s: Real job runtime was: 1 hr 38 min P.S. debug CI job for this PR - 57m In general a well ccached job will only take 7m to compile. P.P.S. comparison with job 7574 - https://www.diffchecker.com/5I31a6oR (50 tests mismatch) |
tools/test.py
Outdated
|
||
if options.time: | ||
# Write the times to stderr to make it easy to separate from the | ||
# test output. | ||
print() |
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 will output an empty tuple in Python 2 (unless from __future__ import print_function
).
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.
Since it's just to add a new line I'd changed it to print('')
tools/test.py
Outdated
cases_to_run = [ c for c in all_cases if not DoSkip(c) ] | ||
return False | ||
return not (FLAKY in case.outcomes and options.flaky_tests == SKIP) | ||
cases_to_run = filter(DoKeep, all_cases) |
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.
Since you're trying to make the script compatible with both Python 2 and Python 3, I don't think this change makes sense. A list comprehension would work identically in either version, but filter
is an iterator in Python 3, so it would raise an exception a few lines below at https://github.com/nodejs/node/pull/23251/files#diff-37479d55e637ac7befeefff7f6d88025R1748.
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 should "pick a lane"... Either new functionality, or 2to3...
I'll give this whole PR another pass. Thanks for the review!
b459ac2
to
b0adcab
Compare
I've refactored this PR into two commits PTAL CI: https://ci.nodejs.org/job/node-test-pull-request/17651/ |
This seems good to me, but should it be two different PRs to ease review? Like, I feel comfortable signing off on one of the commits, but want to be a bit more careful reviewing the other one. If you're OK with being patient, I can spend some time with this to review more thoroughly if other people don't come along and ✔️ it soon... |
8e7acc8
to
453096c
Compare
I reduced the amount of refactoring in the first commit (2b24387). But in order to keep the code for the new feature succinct, I decided to keep four changes:
plus a few trivial changes (non shadowing names, more built in idioms) The second commit (453096c) has the code needed to skip |
def should_keep(case): | ||
if any([ (s in case.file) for s in options.skip_tests ]): | ||
return False | ||
elif SKIP in case.outcomes: |
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.
Nit: Since all the branches return
, these could be simply if
s
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 thought it's seems more readable this way (like a switch)...
671520f
to
41611a8
Compare
41611a8
to
172da2a
Compare
* Hoist common code to base class (`GetTestStatus`, and the `section` property to `TestConfiguration`) * Replace ListSet with the built in set * Remove ClassifiedTest * Inline PrintReport * How cases_to_run are filtered PR-URL: nodejs#23251 Reviewed-By: Rich Trott <rtrott@gmail.com>
they will be skipped if run with `--flaky-tests=skip` PR-URL: nodejs#23251 Reviewed-By: Rich Trott <rtrott@gmail.com>
172da2a
to
deaddd2
Compare
* Hoist common code to base class (`GetTestStatus`, and the `section` property to `TestConfiguration`) * Replace ListSet with the built in set * Remove ClassifiedTest * Inline PrintReport * How cases_to_run are filtered PR-URL: #23251 Reviewed-By: Rich Trott <rtrott@gmail.com>
they will be skipped if run with `--flaky-tests=skip` PR-URL: #23251 Reviewed-By: Rich Trott <rtrott@gmail.com>
* Hoist common code to base class (`GetTestStatus`, and the `section` property to `TestConfiguration`) * Replace ListSet with the built in set * Remove ClassifiedTest * Inline PrintReport * How cases_to_run are filtered PR-URL: #23251 Reviewed-By: Rich Trott <rtrott@gmail.com>
they will be skipped if run with `--flaky-tests=skip` PR-URL: #23251 Reviewed-By: Rich Trott <rtrott@gmail.com>
* Hoist common code to base class (`GetTestStatus`, and the `section` property to `TestConfiguration`) * Replace ListSet with the built in set * Remove ClassifiedTest * Inline PrintReport * How cases_to_run are filtered PR-URL: #23251 Reviewed-By: Rich Trott <rtrott@gmail.com>
they will be skipped if run with `--flaky-tests=skip` PR-URL: #23251 Reviewed-By: Rich Trott <rtrott@gmail.com>
* Hoist common code to base class (`GetTestStatus`, and the `section` property to `TestConfiguration`) * Replace ListSet with the built in set * Remove ClassifiedTest * Inline PrintReport * How cases_to_run are filtered PR-URL: #23251 Reviewed-By: Rich Trott <rtrott@gmail.com>
they will be skipped if run with `--flaky-tests=skip` PR-URL: #23251 Reviewed-By: Rich Trott <rtrott@gmail.com>
* Hoist common code to base class (`GetTestStatus`, and the `section` property to `TestConfiguration`) * Replace ListSet with the built in set * Remove ClassifiedTest * Inline PrintReport * How cases_to_run are filtered PR-URL: #23251 Reviewed-By: Rich Trott <rtrott@gmail.com>
they will be skipped if run with `--flaky-tests=skip` PR-URL: #23251 Reviewed-By: Rich Trott <rtrott@gmail.com>
The target is to get a regular CI job to finish in <= 1h (currently the debug build takes the longest to run).
A more extensive suite will run only once a day.
/CC @nodejs/python @nodejs/testing
CI: https://ci.nodejs.org/job/node-test-pull-request/17613/CI: https://ci.nodejs.org/job/node-test-pull-request/17614/
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes