| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
There was a problem hiding this comment.
Why the name change (isFD -> isFd)?
Sorry, something went wrong.
There was a problem hiding this comment.
That's just reverting the commits from #7168 so test-npm can be run. Not part of the PR.
Sorry, something went wrong.
|
@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 master. Testing these changes will require rebasing/adding the revert commits. Simplicity of code review vs. simplicity of running the tests, not sure which one to prioritise... EDIT: @thealphanerd could you rebase your PR? |
Sorry, something went wrong.
|
Results after initial run: Results on win:1..258 # failed 157 of 258 tests # skip: 1 # time=3884348.615ms 64 min Results on Linux:1..258 # failed 6 of 258 tests # skip: 1 # time=528817.407ms 8.8 min |
Sorry, something went wrong.
There was a problem hiding this comment.
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?
Sorry, something went wrong.
There was a problem hiding this comment.
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.
Sorry, something went wrong.
There was a problem hiding this comment.
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
Sorry, something went wrong.
There was a problem hiding this comment.
@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.
Sorry, something went wrong.
There was a problem hiding this comment.
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
Sorry, something went wrong.
|
@gibfahn Since tools/test-npm.bat is a port of tools/test-npm.sh it would be good to keep the comments from tools/test-npm.sh so that it is easier to compare sections of the batch script to the shell script. |
Sorry, something went wrong.
There was a problem hiding this comment.
Powershell has Tee-Object
Sorry, something went wrong.
|
cc @nodejs/build, the unix script part looks ok to me. |
Sorry, something went wrong.
There was a problem hiding this comment.
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\""
Sorry, something went wrong.
There was a problem hiding this comment.
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.
Sorry, something went wrong.
There was a problem hiding this comment.
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.
Sorry, something went wrong.
|
@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. |
Sorry, something went wrong.
|
tools/test-npm.js? We can always move or rename it later. |
Sorry, something went wrong.
|
FYI: To unblock testing on windows I added a temporary JS-port of tools/test-npm.sh to my node-inspect PR - 144c7dc |
Sorry, something went wrong.
|
@gibfahn What's the status of this? I can review it but it seems to be in need of a rebase. |
Sorry, something went wrong.
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 npm run-script test-node script). 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 citgm ./deps/npm, and it works out of the box. |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
|
Obviously you'd have to get citgm from somewhere, so you could either check it in (makes nodejs/node bigger) or npm install citgm (network dependency). 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). |
Sorry, something went wrong.
|
@nodejs/ctc See #7867 (comment) and #7867 (comment). Opinions on whether to vendor citgm or do something else? |
Sorry, something went wrong.
|
Personally I'm not too thrilled about increasing the size of the repo by that much, so I would prefer alternative options. |
Sorry, something went wrong.
|
@mscdex the options are listed in #7867 (comment), which would you prefer? |
Sorry, something went wrong.
|
@gibfahn What are the downsides to option 2? |
Sorry, something went wrong.
|
@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 2., we can always replace it with citgm if it becomes unmanageable, and I'm also keen to keep the repo small. @jkrems could you put 144c7dc in a separate PR so we can get it reviewed and in? |
Sorry, something went wrong.
|
@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. :) |
Sorry, something went wrong.
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>
| Back | FazBrowse Home | New Git URL |
Checklist
Affected 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 landed
On windows, do set debug=1 to print the TAP output to stdout, otherwise it gets redirected to test-npm.tap (I haven't found a tee equivalent for batch). Now using powershell instead of batch which allows use of Tee-Object
cc @thealphanerd