-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
[WIP] Update test-npm target #7867
Conversation
lib/fs.js
Outdated
@@ -122,6 +142,10 @@ function nullCheck(path, callback) { | |||
return true; | |||
} | |||
|
|||
function isFd(path) { |
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.
Why the name change (isFD
-> isFd
)?
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.
That's just reverting the commits from #7168 so test-npm can be run. Not part of the PR.
852d866
to
e8a503b
Compare
30d289e
to
18125e6
Compare
@thealphanerd I've removed the two revert commits. If I rebase onto #7846 presumably the extra commits will still show up as this PR is against Simplicity of code review vs. simplicity of running the tests, not sure which one to prioritise... EDIT: @thealphanerd could you rebase your PR? |
ae014dc
to
b2d0924
Compare
Results after initial run: Results on win:
64 min Results on Linux:
8.8 min |
tools/test-npm.sh
Outdated
@@ -37,7 +38,7 @@ node cli.js rebuild | |||
# install npm devDependencies and run npm's tests | |||
node cli.js install --ignore-scripts | |||
# run the tests | |||
node cli.js run-script test-node | |||
node cli.js run-script test-node -- --reporter=tap | tee ../test-npm.tap |
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 this not something that could be exposed as a variable. That way we could use different reporters.
This is particularly important as we are having issues currently with the speed of the tap reporter, alternatively using an xunit reporter in CI could prove handy.
As well, I'm not sure that we need to save tap output in all instances, especially when running the tests locally, perhaps there is a way to also expose this behind an option?
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'll add a reporter variable for this and the .bat
.
For the saving, is there a downside to having the .tap
file left behind? It gets sent to the stdout as well. If there's a reporter option, then I could make it so I only set the tee
if --reporter=tap
or --reporter=junit
.
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.
It might be worth trying to replicate the current api exposed by the python test runner. An option to specify reporter, and an option to specify output file name -p tap --logfile test.tap
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.
@thealphanerd So you're saying have a ./configure
option of -p tap
or --reporter tap
and --logfile test.tap
, and Makefile/vcbuild.bat variables called REPORTER
and LOGFILE
?
Follow up: --reporter
or --progress
? I'm leaning towards progress as it's what tools/test.py does.
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 don't think it would necessarily be a configure option. Rather an option that could be passed to the shell script.
If we have that we could easily make a test-npm-ci
job and call the script with the appropriate flags
@gibfahn Since |
tools/test-npm.bat
Outdated
node cli.js rebuild | ||
node cli.js install --ignore-scripts | ||
|
||
rem windows doesn't have tee, so not sure how to get output on screen and in 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.
Powershell
has Tee-Object
cc @nodejs/build, the unix script part looks ok to me. |
tools/test-npm.bat
Outdated
|
||
@rem run the tests | ||
if defined debug ( | ||
node_modules\.bin\tap.cmd --timeout 240 --reporter=tap test\tap |
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.
Why make these different then what we do in the shell script?
If the test-node
target doesn't work on Windows then I'd like to patch that in npm
.
It's important to that what tests get run remain in npm
's control because it is something that will change over time. For instance, in the next release of npm there will be a new folder under test named network
with tests that require the network and the test-node
target will be updated to:
"test-node": "\"$NODE\" \"node_modules/.bin/tap\" --timeout 240 \"test/tap/*.js\" \"test/network/*.js\""
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 was having some problems running it previously, this was a temporary workaround. I agree it makes sense to use the node cli.js run-script test-node
script on windows and fix if necessary.
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.
Aaand, yeah, now that I paste that in it obviously wouldn't work on Windows. Buuut, we're way better about ensuring that the version of node you ran npm with is the one used for lifecycle scripts, so we can actually rewrite that as:
"test-node": "tap --timeout 240 \"test/tap/*.js\" \"test/network/*.js\""
which will work on windows.
0729964
to
a11a97b
Compare
@bnoordhuis Okay, where would you like it? I guess I'd better write it in Node, that way people will be able to review it better. |
tools/test-npm.js? We can always move or rename it later. |
FYI: To unblock testing on windows I added a temporary JS-port of |
@gibfahn What's the status of this? I can review it but it seems to be in need of a rebase. |
Pass -p/--progress and --logfile as you would for tools/test.py Add *test.tap to .gitignore Make test-npm default to using the node binary in out/Release (like tools/test.py). This can still be changed by setting the $NODE environment variable (as before).
test-npm.ps1 should mimic test-npm.sh on Windows. Also adds the test-npm target to vcbuild.bat
@bnoordhuis Rebased (the change to deps/npm is no longer necessary as npm have updated their The issue you raised in #7867 (comment) is that this requires separate scripts for windows and linux. The three ways to go forward with this are:
My preference would be to use citgm, we don't really want to be maintaining two module-testing scripts, and citgm is purpose built for node module testing. You can already do |
Is there a way to make it work with citgm that has zero configuration and zero points of failures? For example, needing to manually check out citgm counts as configuration, automatically checking it out as a potential point of failure. |
Obviously you'd have to get citgm from somewhere, so you could either check it in (makes The reason to use citgm is that it already handles various module testing oddities and works with sandboxing/windows etc. Once you had it you'd be able to use it with other things like node-inspect. Checking it in is what we do with eslint (tools/eslint is 18MB, citgm is about 15MB). |
@nodejs/ctc See #7867 (comment) and #7867 (comment). Opinions on whether to vendor citgm or do something else? |
Personally I'm not too thrilled about increasing the size of the repo by that much, so I would prefer alternative options. |
@mscdex the options are listed in #7867 (comment), which would you prefer? |
@gibfahn What are the downsides to option 2? |
@mscdex I guess the downside is that we'd have to maintain what is essentially a subsection of citgm. The question is how big a subsection it is, if it's small then it's worth doing to keep the size down, if it's large then it becomes less useful. Having taken a look at what citgm is actually doing, I'd say we should go ahead with @jkrems could you put 144c7dc in a separate PR so we can get it reviewed and in? |
@gibfahn I'd rather not open more PRs that I'd have to monitor, I already have 2 long running ones that I have to keep checking. But feel free to "steal" the code and PR it in isolation. :) |
This is continued in #11540 |
Deletes the old test-npm.sh script. PR-URL: nodejs#11540 Refs: nodejs#7867 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com>
Deletes the old test-npm.sh script. PR-URL: nodejs/node#11540 Refs: nodejs/node#7867 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com>
Deletes the old test-npm.sh script. PR-URL: nodejs/node#11540 Refs: nodejs/node#7867 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com>
Checklist
make -j4 test-npm
(UNIX), orvcbuild test-npm
(Windows) passesAffected core subsystem(s)
test, npm
Description of change
Update the test-npm script to generate tap output, and add a windows version.
N.B. If the
deps/npm
change will be upstreamed in npm/npm#13735.Ref: nodejs/build#317
CI: https://ci.nodejs.org/view/All/job/gibfahn-test-npm/
Windows CI: https://ci.nodejs.org/job/gibfahn-test-npm-win
Known Issues
test-npm
is currently failing due to npm/npm#13457 which seems to be caused by #7168 (see #7168 (comment) for more info).I've also seen failures due to npm/npm#12220.
Manual testing
Build gibfahn:rebased-test-npm-fix to get the #7168 revert as well.Shouldn't be necessary now #7168 has landedOn windows, doNow using powershell instead of batch which allows use of Tee-Objectset debug=1
to print the TAP output to stdout, otherwise it gets redirected to test-npm.tap (I haven't found atee
equivalent for batch).cc @thealphanerd