feat(watch): migrate to fsnotify

[andreynering]

We're migrating from watcher to fsnotify, which is more performant and will avoid issues with high CPU usage.

This will close the following issues:

• Use fsnotify instead of watcher #1508
• Extremely high CPU usage with -w #985
• Task is not getting re-executed after addition/deletion of files when used with --watch argument.  #1179

TODO:

• fsnotify recommends us to watch directory instead of individual files.
  • Add a function to internal/fingerprint to return only the directories and watch for those.
  • When an event comes, we'll need to double check if the file is included in sources.
• Mark the --interval flag and interval: setting as deprecated. We should probably emit a warning if set, as from now on these will be ignored.
  • I actually reconsidered this and I'm reusing the interval setting as the time we wait for suplicated events. Changed default from 5 seconds to 100ms.
• Dedup duplicated events

Possible post-launch improvements:

• Task is not getting re-executed after addition/deletion of files when used with --watch argument.  #1179 (comment)
• watch: interrupt ongoing task #160

[pd93]

I'm having issues where if a directory is empty when I start the watcher and then create files, nothing will be detected. If I create any file before starting the watcher, then other new files are detected.

I'm also not able to get deletes to work (on Linux). When I remove a file, I just get something like this:

task: received watch event: WRITE         ".../testdata/watcher_interval/src/foo.txt"
task: skipped for file not in sources: src/foo.txt

But it does not start the task.

[radcool]

I'm having issues where if a directory is empty when I start the watcher and then create files, nothing will be detected. If I create any file before starting the watcher, then other new files are detected.

I've observed the same thing.

[andreynering]

I'm still going to work on this issue another day.

[andreynering]

@pd93 @radcool I just pushed fixes for both of the issues you reported.

[pd93]

This is looking good now! (At least on Linux). I can't see any unexpected behaviour and the previously mentioned issues seem to be fixed. Performance also seems much better than before.

I can't speak to the remaining points around ulimits on MacOS (I don't own any Apple hardware), but it seems like regardless of that issue, this is a big step forwards and those things could be addressed separately if required. I think for most users, the default ulimit will be enough and CGO seems like a line we can't cross in Task anyway.

[andreynering]

I'm merging this as this is an significant improvement on it already. We can still do further improvements with time. 🙂