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

Added feature to poll files for help with virtual machines/docker #9

Closed
carsongee opened this issue May 6, 2015 · 8 comments · Fixed by #10
Closed

Added feature to poll files for help with virtual machines/docker #9

carsongee opened this issue May 6, 2015 · 8 comments · Fixed by #10

Comments

@carsongee
Copy link
Contributor

We do a lot of our development in docker, and the events for changed files are generated in the host OS instead of inside docker, so ptw doesn't see that files have changed. Do you have any interest in adding a polling option, that will just scan the folder for modified file times and trigger tests? I may be able to write the code if you are.

@joeyespo
Copy link
Owner

joeyespo commented May 6, 2015

Hi, @carsongee. Perhaps.

Actually, do you think this is a watchdog bug? If the files are indeed changing, watchdog should pick it up regardless if it's running in a container or not. Or am I misunderstanding?

@carsongee
Copy link
Contributor Author

I just checked their repo, and found a very similar issue: gorakhargosh/watchdog#283. So it isn't really designed to handle events on remote file systems like we have with mounted container volumes since it is just using kernel events, so if you run watchdog in the container, since the kernel in the container isn't firing the event, the one in the host OS is, the watchdog can't react to it.

@joeyespo
Copy link
Owner

joeyespo commented May 8, 2015

Good find!

Looks like watchdog provides a decent workaround with PollingObserver.

It'd be great it watchdog was able to detect whether inotify was reliable or not, so you wouldn't need an application-level concern. This is, in my opinion, a leaky abstraction that watchdog could potentially plug up. (Interested in opening a new issue asking for them to look into this? Docker is indeed growing in popularity.)

We could look at other libraries to see if they work inside of Docker out-of-the-box so pytest-watch users don't have to waste any time with this surprise. In the short-term, adding an option to use polling should be ok. I'd happily pull in a PR if you wanted to add a --poll option.

carsongee added a commit to carsongee/pytest-watch that referenced this issue May 8, 2015
@carsongee
Copy link
Contributor Author

I added the PR. As to reporting it upstream, are you thinking the issue would be to have the standard observer figure out if it needs to use polling? That would be pretty cool. I don't think there is any other way to address it in watchdog since the nature of remote filesystems is not to generate kernel events, that would have to be a fix in Mac and Linux kernels I think, but I'm a little out of my depth on this.

@joeyespo
Copy link
Owner

joeyespo commented May 8, 2015

are you thinking the issue would be to have the standard observer figure out if it needs to use polling

Exactly. Then all tools that use watchdog would just work under this scenario instead of having to implement their own custom solutions.

I believe it's possible. For instance, one (bad) way would be to have watchdog create a .watchdog file and delete it right away in the directory it's observing. If no kernel events happen, turn on polling.

@carsongee
Copy link
Contributor Author

@joeyespo
Copy link
Owner

joeyespo commented May 8, 2015

@carsongee Thank you!

@joeyespo
Copy link
Owner

FYI Released pytest-watch 3.0.0 today, which includes --poll.

Be sure to pip install --upgrade pytest-watch 😃

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

Successfully merging a pull request may close this issue.

2 participants