Context
The CI workflows (Build and Release) invoke Gradle via ./gradlew without --no-daemon. By default this starts a long-lived Gradle Daemon for every job, which is wasteful in ephemeral CI environments:
- Each daemon JVM consumes memory (often 512MB+), and one is started per job/matrix entry.
- The daemon is never reused across runs since runners are ephemeral, so it only adds startup cost and resource usage.
- CI environments are single-build, so there is no benefit from daemon reuse.
Task
Ensure the Gradle invocations in the workflows do not start a daemon. Options:
- Add
--no-daemon to each ./gradlew invocation in .github/workflows/github.yml and .github/workflows/release.yml.
- Alternatively, set
org.gradle.daemon=false in a CI-specific gradle.properties (or via GRADLE_OPTS/environment in the workflow).
Note the gradle plugin build and example-server/client/client-kotlin builds run as separate ./gradlew -p ... invocations in the same job; ensure none of them spawn a daemon.
Acceptance criteria
- No Gradle Daemon process is started during CI runs (verifiable via
--info output or by checking the daemon registry).
- Existing builds keep working without behavioral changes.
Context
The CI workflows (Build and Release) invoke Gradle via
./gradlewwithout--no-daemon. By default this starts a long-lived Gradle Daemon for every job, which is wasteful in ephemeral CI environments:Task
Ensure the Gradle invocations in the workflows do not start a daemon. Options:
--no-daemonto each./gradlewinvocation in.github/workflows/github.ymland.github/workflows/release.yml.org.gradle.daemon=falsein a CI-specificgradle.properties(or viaGRADLE_OPTS/environment in the workflow).Note the gradle plugin build and example-server/client/client-kotlin builds run as separate
./gradlew -p ...invocations in the same job; ensure none of them spawn a daemon.Acceptance criteria
--infooutput or by checking the daemon registry).