-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
Retry long path tests on Linux under real tmp dir #3929
Conversation
if (os.type() == 'Linux') { | ||
fs.accessSync(os.tmpdir(), fs.R_OK | fs.W_OK); | ||
var tmpDir = path.join(os.tmpdir(), | ||
'node-' + process.version + '-test-' + (Math.random() * 1e6 | 0)); |
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.
use a template string to shorten this
https://ci.nodejs.org/job/node-test-pull-request/793/ I think as long as you're basically rewriting all of this you may as well replace all the |
See comments to PR #3929
lgtm pending https://ci.nodejs.org/job/node-test-pull-request/794/ @rsp squash the commits into one and follow the format outlined in https://github.com/nodejs/node/blob/master/CONTRIBUTING.md#step-3-commit for the message. |
@rsp you didn't have to create a new PR. You can force push to the same branch to update this one. |
Using Another less elegant way to do this is to delete or rename your local copy of this branch, make a new one and do what you need on it and use |
No problems @rsp, you'd actually be force pushing to your own fork so that doesn't create any hassles on this end. Thanks for the contribution and presuming this lands without objection in a day or two, welcome to the club of contributors, hopefully we'll be seeing more from you! |
@rvagg My pleasure, thanks for your help. I hope I'll be able to contribute something useful. By the way, those two tests that I was working with were just throwing exceptions and printing long stack traces so I had to find the relevant lines in source code to see what's going on. I kept it that way but maybe it would be useful to print a more meaningful message instead of the stack trace in those two or other similar tests? I don't know if there is any guide for writing good tests that describes how a good output should look like, I haven't found it in CONTRIBUTING.md or COLLABORATOR_GUIDE.md. Maybe there is some room for improvement to make tests print few lines of relevant info instead of stack traces? If so, I'll be happy to help with that. |
An alternative to this would be changing path to tmpdir (#3325) but having a default state of "Just Working" is nice. LGTM. |
testFsLongPath(common.tmpDir); | ||
common.refreshTmpDir(); | ||
} catch (e) { | ||
if (os.type() == 'Linux') { |
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.
perhaps use process.platform == 'linux'
instead?
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.
@jbergstroem Yes, it would be the same. This code already uses the os
module for other things so it seemed to make sense to use the normalized name for the comparison but it could test process.platform
or os.platform()
just as well as os.type()
. I can change it if that's what's holding the PR #3936 back.
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.
process.platform
is a little more idiomatic, at least w.r.t. to the test suite.
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.
@bnoordhuis @jbergstroem Done. It's using process.platform now. See: 2f5ca5d
@jbergstroem changing path to tmpdir would be perfect - much better than what I did here. This was actually the first thing that I tried but changing But I agree that optionally changing the temp dir for all tests would be much better and breaking so many tests by changing it is probably a sign of a more serious problem (having tmp.0, tmp.1, tmp.2, tmp.3, tmp.4, tmp.5, tmp.6, tmp.7 directories left in |
@rsp I have a few fixes I will push to PR in a day or three. Feedback appreciated! |
@jbergstroem Great, thanks. By the way, I created a new PR #3936 - see comments above. It is the same as this one but with one commit as suggested in the comments here. (I didn't know that the practice here is to force push squashed commits to public PR branches, so I thought I need to create a new PR with squashed commits to avoid losing diff comments like yours.) |
@rsp no need to squash until its ready for merge. |
@jbergstroem OK, maybe I misunderstood the previous comments. This is my first contribution here so I'm still learning how things work here. Thanks for your help. |
@jbergstroem You said about fixes to this PR that you want to push a week ago. If you don't have time then let me know what needs to be fixed and I'll change it. Thanks. |
I'm not sure if I'm okay with adding hacks for something as niche as ecryptfs, the more so because the workaround is quite involved. |
@bnoordhuis This test is made for Windows. You don't really have to test long path support on Linux to see if the long path support is working correctly in Node - you only have long/short path issues on Windows. The problem is that those two tests while reasonable on Windows fail on default Ubuntu installations that makes the entire Node look like it hasn't compiled correctly and if you run |
Wouldn't it make more sense in that case to skip the test when |
@bnoordhuis Maybe but I thought that running the test would be more preferable than skipping it, to make sure that it is indeed just the wrong place to run it instead of lacking the required functionality. What I did is to run it in real system tmp if it fails in $PWD but as always there's more than one way to do it. If there is consensus on how it should be done differently then I will be happy to change it but I thought @rvagg and @targos were ok with how it is done right now so I don't want to skip the test entirely without hearing their opinion first. |
@jbergstroem Sorry, I misunderstood you. I hope your PR gets support and the system temp dir will be the default temp path for Node tests. |
@rsp fyi I won't change defaults - there'll probably be too many problems with that (esp cross-filesystem issues). |
@jbergstroem Oh, I see. So unfortunately we would still need this PR (or skipping those two tests entirely on Linux as suggested by @bnoordhuis) to have the tests work on Ubuntu. Personally I can live with those tests failing because I can always inspect the stack trace every time I run |
@rsp; not really -- you'd pass |
Any updates on this one? |
@jasnell The issue #2255 was closed by pr #4116 which doesn't really fix those tests but skips them instead (personally I'd prefer running the corrected tests that work fine instead of skipping them but at least now |
Use os.tmpdir() on Linux if it is readable/writable
but only when the original tests fail
in test-fs-long-path.js and test-require-long-path.js
to avoid failing tests on ecryptfs filesystems
See issue #2255 and comments to PR #3925