Skip to content
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

Closed
wants to merge 2 commits into from
Closed

Conversation

gibfahn
Copy link
Member

@gibfahn gibfahn commented Jul 25, 2016

Checklist
  • make -j4 test-npm (UNIX), or vcbuild test-npm (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines
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

@nodejs-github-bot nodejs-github-bot added the meta Issues and PRs related to the general management of the project. label Jul 25, 2016
@ChALkeR ChALkeR added wip Issues and PRs that are still a work in progress. test Issues and PRs related to the tests. tools Issues and PRs related to the tools directory. and removed meta Issues and PRs related to the general management of the project. labels Jul 25, 2016
lib/fs.js Outdated
@@ -122,6 +142,10 @@ function nullCheck(path, callback) {
return true;
}

function isFd(path) {
Copy link
Contributor

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)?

Copy link
Member Author

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.

@mscdex mscdex added the npm Issues and PRs related to the npm client dependency or the npm registry. label Jul 25, 2016
@gibfahn gibfahn force-pushed the test-npm-fix branch 2 times, most recently from 852d866 to e8a503b Compare July 25, 2016 15:04
@MylesBorins
Copy link
Contributor

@gibfahn there is already a PR in for the revert against fs

#7846

might be better to keep the two separated for the sake of simplicity. Perhaps you can build this PR on top of #7846?

@gibfahn gibfahn force-pushed the test-npm-fix branch 2 times, most recently from 30d289e to 18125e6 Compare July 25, 2016 16:39
@gibfahn
Copy link
Member Author

gibfahn commented Jul 25, 2016

@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?

@gibfahn gibfahn force-pushed the test-npm-fix branch 3 times, most recently from ae014dc to b2d0924 Compare July 25, 2016 17:02
@gibfahn
Copy link
Member Author

gibfahn commented Jul 25, 2016

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

@@ -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
Copy link
Contributor

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?

Copy link
Member Author

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.

Copy link
Contributor

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

Copy link
Member Author

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.

Copy link
Contributor

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

@richardlau
Copy link
Member

@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.

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Powershell has Tee-Object

@Fishrock123
Copy link
Contributor

Fishrock123 commented Jul 26, 2016

cc @nodejs/build, the unix script part looks ok to me.


@rem run the tests
if defined debug (
node_modules\.bin\tap.cmd --timeout 240 --reporter=tap test\tap
Copy link
Member

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\""

Copy link
Member Author

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.

Copy link
Member

@iarna iarna Jul 28, 2016

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.

@gibfahn
Copy link
Member Author

gibfahn commented Dec 13, 2016

@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.

@bnoordhuis
Copy link
Member

tools/test-npm.js? We can always move or rename it later.

@jkrems
Copy link
Contributor

jkrems commented Dec 14, 2016

FYI: To unblock testing on windows I added a temporary JS-port of tools/test-npm.sh to my node-inspect PR - 144c7dc

gibfahn added a commit to gibfahn/node that referenced this pull request Dec 28, 2016
@bnoordhuis
Copy link
Member

@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
@gibfahn
Copy link
Member Author

gibfahn commented Jan 24, 2017

@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:

  1. Use this as is (tools/test-npm.sh already exists, so it's the least change.
  2. Use @jkrems's js port in 144c7dc
  3. Include citgm in nodejs/node increases repo size by ~15MB.
  4. Do an npm install citgm as part of make test-npm (requires internet access).

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.

@bnoordhuis
Copy link
Member

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.

@gibfahn
Copy link
Member Author

gibfahn commented Jan 24, 2017

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).

@bnoordhuis
Copy link
Member

@nodejs/ctc See #7867 (comment) and #7867 (comment). Opinions on whether to vendor citgm or do something else?

@mscdex
Copy link
Contributor

mscdex commented Jan 24, 2017

Personally I'm not too thrilled about increasing the size of the repo by that much, so I would prefer alternative options.

@gibfahn
Copy link
Member Author

gibfahn commented Jan 25, 2017

@mscdex the options are listed in #7867 (comment), which would you prefer?

@mscdex
Copy link
Contributor

mscdex commented Jan 25, 2017

@gibfahn What are the downsides to option 2?

@gibfahn
Copy link
Member Author

gibfahn commented Jan 31, 2017

@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?

@jkrems
Copy link
Contributor

jkrems commented Jan 31, 2017

@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. :)

@gibfahn
Copy link
Member Author

gibfahn commented Feb 24, 2017

This is continued in #11540

@gibfahn gibfahn deleted the test-npm-fix branch June 3, 2017 14:34
gibfahn added a commit to gibfahn/node that referenced this pull request Oct 19, 2017
Deletes the old test-npm.sh script.

PR-URL: nodejs#11540
Refs: nodejs#7867
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Refael Ackermann <[email protected]>
MylesBorins pushed a commit that referenced this pull request Oct 23, 2017
Deletes the old test-npm.sh script.

PR-URL: #11540
Refs: #7867
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Refael Ackermann <[email protected]>
addaleax pushed a commit to ayojs/ayo that referenced this pull request Oct 26, 2017
Deletes the old test-npm.sh script.

PR-URL: nodejs/node#11540
Refs: nodejs/node#7867
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Refael Ackermann <[email protected]>
addaleax pushed a commit to ayojs/ayo that referenced this pull request Dec 7, 2017
Deletes the old test-npm.sh script.

PR-URL: nodejs/node#11540
Refs: nodejs/node#7867
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Refael Ackermann <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
npm Issues and PRs related to the npm client dependency or the npm registry. test Issues and PRs related to the tests. tools Issues and PRs related to the tools directory. wip Issues and PRs that are still a work in progress.
Projects
None yet
Development

Successfully merging this pull request may close these issues.