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

when watching, add ability to ignore hidden files (including tests!) #1401

Open
ewollesen opened this issue May 1, 2024 · 5 comments
Open

Comments

@ewollesen
Copy link
Contributor

When watching for changes, I find that ginkgo will detect a change and run the test suite when a new test file is created, even if that test file doesn't match the watch regexp.

For example, if I have a this project layout:

foo.go
foo_test.go

...and then I run:

gingko watch -r --watch-regexp='^[^.].*\.go$'

...then when I create a file ".#foo_test.go", the suite will be run.

I believe this is because it matches goTestRegExp defined at https://github.com/onsi/ginkgo/blob/master/ginkgo/watch/package_hash.go#L11, which is evaluated at https://github.com/onsi/ginkgo/blob/master/ginkgo/watch/package_hash.go#L82 and found to have changes.

So the watch regexp isn't able to prevent this behavior.

I've worked up two different ways to work around this behavior, and would be glad to present a PR for either, if this seems like a reasonable ask.

My first (simpler) solution, is just to basically move line 90 in package_has.go to line 81, which effectively makes the watch regexp apply to test files as well as code files. I'm not sure if that's desireable behavior though. I can't think of any cases where a test file wouldn't be matched by the watch regexp, but I'm sure I haven't thought about this as much as the authors.

For a more involved solution, I have a branch that adds an "--ignore-hidden-files" flag to the watch command which just ignores any file with a name that begins with ".". Not sure how this could/should/would be handled for Windows filesystems though..?

Why is this something I even care about? My editor (Emacs), creates a temporary backup file whenever I modify a file. As a result, whenever I modify a test file, my test suite is triggered, which is a waste of time and resources, and can trick me into thinking the suite has passed when it hasn't.

@ewollesen ewollesen changed the title when watching, add ability to ignore hidden files when watching, add ability to ignore hidden files (including tests!) May 1, 2024
@onsi
Copy link
Owner

onsi commented May 2, 2024

hey @ewollesen this is great, thank you!

but I'm sure I haven't thought about this as much as the authors

I can assure you that, at this point, you absolutely have!

the issue and use-case all make sense to me. I think adding --ignore-hidden-files makes sense though I'm wondering if this should be the default behavior going forward. What if instead we add --include-hidden-files as a configuration option in case folks want to monitor hidden files but, other than that, ginkgo watch by default should ignore hidden files.

Thoughts? A PR would be great!

@ewollesen
Copy link
Contributor Author

Thoughts? A PR would be great!

Sounds good. I think it does make more sense logically to ignore files starting with '.' by default. The only potential downside I see is that anyone that's used to the behavior could be caught unaware by the change. That said, I rather doubt anyone is creating hidden files with tests in them. Hopefully it won't break anyone's processes.

I'll re-work my version with the flag and push a PR ASAP.

@ewollesen
Copy link
Contributor Author

Heh, out of curiousity, I just checked, and 'go test' ignores hidden files by default. I don't see a flag for enabling the behavior.

They include this in the output of go help test:

Files whose names begin with "_" (including "_test.go") or "." are ignored.

@onsi
Copy link
Owner

onsi commented May 5, 2024

Good call to check. I think we can just follow its behavior - if anyone opens an issue we can add the flag later. Sound reasonable?

@ewollesen
Copy link
Contributor Author

That sounds fine to me. It makes the PR simpler too. :)

PR #1405 is ready for you when you have a few minutes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants