mirror of
https://github.com/vitorpamplona/amethyst.git
synced 2026-10-06 03:38:23 +00:00
Claude
48bb8d37e3
test-and-build-android died again with "the runner has received a shutdown signal" — the OOM killer taking the runner agent, about 20 minutes in, with every task up to that point green. No test failed and nothing failed to compile. The previous fix is not wrong, it was validated on the easy case.ea459bc5changed only this file, so the run restored main's Gradle cache and rebuilt almost nothing; it passed in 54 minutes and I read that as confirmation. The first PR run since that touches `commons` invalidated the cache — this job's own comment above notes a quartz/commons change does exactly that and costs 2-3x — rebuilt from cold, and died the same way. Cold is the case the 4g cap had never actually faced. So the lever is concurrency rather than ceilings. Those heap numbers are per-JVM limits; what tips a 16GB runner over is how many heavy JVMs are resident at once, and Gradle defaults max-workers to the core count with org.gradle.parallel on. The log shows the peak: R8 and both lintAnalyze tasks behind it, a cold compileFdroidDebugKotlin, and a forked test JVM starting, alongside the 6g Gradle and 4g Kotlin daemons. --max-workers=3, not 2. This job is mostly a chain of single-task module compiles, so it loses little real parallelism, and halving it risks the timeout on a cold run instead — the cap goes to 120 for that reason, which costs nothing on runs that finish early. Dropping the Kotlin daemon further was the obvious alternative and is the wrong one:cdb4f1f7already lost that trade, starving R8 and lintAnalyze into "java.lang.OutOfMemoryError: Java heap space". If this still dies early, the job is simply too big for one 16GB runner and the answer is splitting lint out into its own job — not another number. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AXvKXakvup4inNFfAhhr4L