Thanks for reporting @ymwang1984 . Sorry for the delay. Interestingly, if you run ./gradlew runPlayBinary -t with -t (or --continuous), the build will run only once.
The first build runs the real build (compile/assemble/start server), if Gradle finds there’s any “deployment” running after the first build finishes, it will enter continuous build mode automatically - the second build.
I don’t know why we made this change in 4.2, but this does look like an expected behaviour. I’d say this doesn’t look good, and I’d like to see only one build in this scenario.
I want to make sure if this does any harm to you? Or it’s just annoying?
As described in the PR, this change was done to support a workflow desired by Play developers. Instead of triggering a rebuild of the app on every single change, we wait until an HTTP request is made before rebuilding.
The fact that we execute the build twice on initial startup is a bug. But any fix will need to retain the “build on demand” functionality introduced in #2830.
Thanks for confirmation. Can we fix this behavior? The user experience is not great with duplicate runs and it also slows down the build.
Another thing is that can we have a mode of “runPlayBinary” to NOT have hot reload?
Before Gradle 4.2, “runPlayBinary” (without “-t”) is the mode without reload. In our company’s CI environment, somehow we have very low file watcher limit for better stability, and that breaks “runPlayBinary” (since it requires high file watcher when the code base is large).