Documentation: Recommend running Gradle with --no-daemon flag

[boxleytw]

This issue is specific to Gradle builds with Batect.

The documentation should mention using the --no-daemon flag for running Gradle in batect.yml. Several reasons:

• There is no point in spinning up a daemon for a Docker ephemeral container
• With a daemon, the Docker container's Gradle may be confused by ~/.gradle/daemon and /.gradle/workers directories, as these refer to processes in the host, not the container
• If you encounter troubles, run locally ./gradlew --stop to kill any local daemons: This indicates a bug, and "stop" is a workaround

[charleskorn]

Hey @boxleytw, https://batect.dev/tools/Gradle.html describes setting the GRADLE_OPTS environment variable to -Dorg.gradle.daemon=false, which has the same effect as --no-daemon.

[binkley]

I've been tracking this locally in https://github.com/binkley/modern-java-practices which provides strawman builds for Gradle and Maven on a trivial project.

Presently, both Gradle and Maven builds with Batect (build-gradle and build-maven, respectively) work.

I'm encountering confusing issues with Gradle builds only. This may not be Batect's issue, but Gradle's.

I need to update my batect.yml to exclude "local" vs "container" directories when mounting my ~/.gradle dir (mounting avoids redownloading dependencies). Running ./gradlew --stop before ./batect <some build involving gradle> resolves things otherwise.

@charleskorn Do you have any PRs from folks on the documentation? If not, I'm happy to provide a doc-only PR. I've read comments here and elsewhere on better mount configurations to address Gradle's peculiarities

[charleskorn]

My general advice to anyone using Gradle is to mount a separate cache volume for ~/.gradle instead of using a mounted directory from the host. On macOS and Windows, the I/O performance of a mounted directory is pretty terrible, and then there are also issues like these that make it unreliable.

[binkley]

I'm unable to close this. :)