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

Scan for test helpers causes error when non-accessible folders present #1793

Closed
maritz opened this issue May 11, 2018 · 6 comments · Fixed by #2103
Closed

Scan for test helpers causes error when non-accessible folders present #1793

maritz opened this issue May 11, 2018 · 6 comments · Fixed by #2103
Labels
bug current functionality does not work as desired help wanted scope:globbing

Comments

@maritz
Copy link

maritz commented May 11, 2018

Description

When there is a directory in your project that is unaccessible by the user runnig the tests, ava runs into an error during startup and exits.

In my case this is a volume created by the postgresql docker image and it resets the directory permissions on every start.

The problem is that the defaultHelperPatterns are set in a way that tries to read all directories and cannot be changed afaict.

Error Message & Stack Trace

glob error { Error: EACCES: permission denied, scandir '/home/maritz/{redacted}/db-volume/test'
  errno: -13,
  code: 'EACCES',
  syscall: 'scandir',
  path: '/home/maritz/{redacted}/db-volume/test' }
/home/maritz/{redacted}/node_modules/ava/lib/cli.js:206
					throw err;
					^

Error: EACCES: permission denied, scandir '/home/maritz/{redacted}/db-volume/__tests__/helpers'
    at handlePaths (/home/maritz/{redacted}node_modules/ava/lib/ava-files.js:14:18)
    at AvaFiles.findTestHelpers (/home/maritz/{redacted}/node_modules/ava/lib/ava-files.js:140:10)
    at Api._precompileHelpers (/home/maritz/{redacted}node_modules/ava/api.js:140:5)
    at _setupPrecompiler.then (/home/maritz/{redacted}/node_modules/ava/api.js:167:21)
    at <anonymous>

Making it work locally

When going manually into

const defaultHelperPatterns = () => [
and changing the defaultHelperPatterns to only scan my src folder it works fine.

const defaultHelperPatterns = () => [
  'src/**/__tests__/helpers/**/*.js',
  'src/**/__tests__/**/_*.js',
  'src/**/test/helpers/**/*.js',
  'src/**/test/**/_*.js',
];

Fix options?

I see two ways to properly fix this (aside from removing inaccessible directories):

  1. Add an option to change the defaultHelperPattern (related to Too slow in large projects #1418 (comment))
    or
  2. Catch EACCES errors and print out a warning and continue
@novemberborn novemberborn added bug current functionality does not work as desired scope:globbing labels May 11, 2018
@novemberborn
Copy link
Member

Sorry you're running into this @maritz. We do need to change how we select files but it's a larger change. I haven't been able to focus on that part of the project unfortunately.

Ignoring EACCESS errors isn't great either, as it means one day helpers work, and then the next they won't, and you wouldn't know why.

I've done a lot of thinking on this previously, but then didn't get round to implementing anything. Regardless of where we end up eventually, I think it should be possible to disable helper compilation altogether. That is something we could add now. What do you think?

Setting "helpers": false in AVA's configuration could do it. We can later expand that to take custom patterns.

@maritz
Copy link
Author

maritz commented May 11, 2018

It would fix my specific issue, for sure. Not sure it's the best long-term solution for everyone though.

I am curious though: Why would printing an error and ignoring potentially cause breakage in your opinion?

@novemberborn
Copy link
Member

Not sure it's the best long-term solution for everyone though.

It's not, but it's a feature we'll end up having anyway, and it fixes some problems now.

Why would printing an error and ignoring potentially cause breakage in your opinion?

I assume the error will mean we don't find any helper files. So one day AVA compiles your helpers, and the next it doesn't, because there's a directory it can't traverse. Know you're left wondering why helper compilation stopped working.

@maritz
Copy link
Author

maritz commented May 12, 2018

you're left wondering why helper compilation stopped working.

Well, it would log out a warning about the inaccessible directories. But if the user makes the directory that contains his helpers inaccessible (or something else does), it's not gonna work anymore anyways, right?!

@novemberborn
Copy link
Member

We only get all glob results or an error, so we can't warn. Long term we'd want to exit with an error and have users exclude those directories from the helpers. For now let's ship a way to disable helper compilation.

@maritz
Copy link
Author

maritz commented May 13, 2018

Oh. that makes sense. 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug current functionality does not work as desired help wanted scope:globbing
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants