mirror of
https://github.com/vitorpamplona/amethyst.git
synced 2026-10-05 11:18:24 +00:00
test-and-build-android has now died with "the runner has received a shutdown signal" seven times in this workflow's history — SIGTERM, exit 143, the OOM killer taking the runner agent on a 16GB box. Twice on this PR alone:2cd6569fat 35 minutes during compileFdroidDebugKotlin,f5fc432eat 29.5 minutes during testFdroidDebugUnitTest. Neither had a failing test; the job is simply killed, which is why the report steps come back "skipped" rather than red. Two attempts to fix this by changing numbers are already spent, and the existing comments in this file record both. Capping both daemons to 4g traded the runner OOM for an R8/lintAnalyze "java.lang.OutOfMemoryError: Java heap space" — those draw on the Gradle daemon's heap and 4g is not enough for them here. Dropping to --max-workers=3 survives a warm cache but still dies on a cold one, which is the case that matters: a PR touching quartz or commons invalidates the read-only cache the PR runs restore, so they rebuild from cold at 2-3x the main-branch time. Every commit on this PR touches commons. So this is the structural fix rather than a third number. lintAnalyze is the single heaviest step in that job — 13 of the 35 minutes on the2cd6569frun — and it holds a large analysis graph while the Kotlin daemon, a forked test JVM and R8 are still resident. Moving the two lint tasks to their own runner removes that peak from the critical job instead of trying to squeeze everything under one ceiling, and the two now run concurrently rather than in series. The cost is real and worth stating: both jobs restore the same read-only Gradle cache and therefore repeat some module compilation. That trade is favourable because the duplicated work is parallel while the memory pressure was not. Nothing about the tasks themselves changes — same task names, same daemon caps, same --max-workers. The lint-report artifact upload moves to the new job. Not verified locally: lintPlayBenchmark is a 13-minute task on CI hardware and this container is the same shape as the runner that keeps dying, so running it here would prove nothing useful. What is checked is that the workflow still parses, that lint-android carries needs: lint like its sibling, and that the android job no longer references the lint tasks. CI is the test for this one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AXvKXakvup4inNFfAhhr4L