I have a multi-module Gradle project with a decent number of files which I supposed potentially could have benefited from using the new --watch-fs feature. But, actual CI logs don’t show any usage of the FS retention on consecutive builds.
Starting a Gradle Daemon (subsequent builds will be faster)
Watching the file system is an incubating feature.
Spent 19 ms registering watches for file system events
Virtual file system retained information about 0 files, 0 directories and 0 missing files since last build
...
BUILD SUCCESSFUL in 1m 37s
4000 actionable tasks: 4000 from cache
Virtual file system retains information about 0 files, 0 directories and 0 missing files till next build
After reading the official documentation I concluded that feature is not applicable for CI systems as all FS changes are stored in the memory of the Gradle daemon process. Which according to my knowledge does not survive between CI system build runs.
To detect changes on the file-system, and to calculate what needs to be rebuilt, Gradle collects information about the file-system in-memory during every build (aka Virtual File-System ).
I’d appreciate it if somebody can confirm/deny the statement of the uselessness of using this option on CI systems. And if the VFS information gets persisted somewhere which place is it (I clean some of the .gradle/caches folders after each build)?
Hi @Lance, thank you for clearing this up. Looks like I totally misunderstood the purpose of the feature. My expectations were to see the N milliseconds boost in build time by having more consistent VFS as the documentation stays:
By watching the file-system, Gradle can keep the Virtual File-System in sync with the file-system even between builds. Doing so allows the Daemon to save the time to rebuild the Virtual File-System from disk for the next build.
I didn’t find any references in the documentation that it would actually trigger a new build when changes are made on FS. But, if it works as you mentioned, I guess this could be a very helpful in case of IDE using.
Allow me to backtrack… I was getting the new --watch-fs feature confused with --continuous (see continuous build). Please disregard my previous response.
I’ve always used clean workspaces on CI agents (rather than dirty/incremental workspace) so I’m not sure that --watch-fs would be useful to me in a CI scenario. I’m guessing it might be useful when you only have one or two CI agents (so you’ll often get the same agent(s) for the same build), again this is not how my CI agents work.
The VFS is an in-memory-only feature, and data in it can only be reused between builds running on the same daemon. If you (or your CI server) kills the daemon after every build, then you won’t benefit from file system watching.
That said, it is okay to leave the feature enabled even in this case: there should be no downsides, and we are also planning to enable it by default in Gradle 7.0 anyway.
We are also planning some further uses for file system watching that could be useful on CI as well. One of these features is to ensure that tasks don’t modify their inputs while the build is running.