:wave: Wanted to get thoughts on if people are usi...
# gradle
r
👋 Wanted to get thoughts on if people are using non-ephemeral CI agents for their gradle builds? If they do • how frequent they run into issues similar to local machine we see from time to time, related to corrupt build cache, daemon cache, KSP/Kapt issue etc.. ◦ Some kind of clean up job or script to orchestrate it?
I believe cache re-use across builds/runs can be achieved using https://github.com/gradle/actions/blob/main/docs/setup-gradle.md#caching-build-state-between-jobs - is it really worth having both non-ephemeral + gradle-action-cache.
v
if people are using non-ephemeral CI agents for their gradle builds
yes
how frequent they run into issues
Once when aborting a build in an unlucky moment that triggered a bug that caused a poisened local build cache on the build agent as well as a poisened remote cache, so even with ephemeral agents the problem would have been the same.
Some kind of clean up job or script to orchestrate it?
No
blob ty sign 1
r
Something i need to benchmark and evaluate or see - gradle-action-cache, does most of the jobs looking at their doc, maintaining cache per PR or a global cache for things like dependency cache, wrapper etc.. Configuration-cache support to be added in future. Only disadvantage theoretically i see - is not able to re-use daemons, across builds/runs and hence spending some additional time on forking JVM and stuff it does every time. I believe one can still get the advantage of local cache + config cache in ephemeral agent with use of gradle-action-cache.
Definitely, it needs some tests to run and weigh the benefits from my end.
n
We use non-ephemeral CI agents (M1 Mac Mini, 16 GB RAM) for our KMP, Android and iOS builds. We run 2 "runner" instances a single machine, and the only issues we've experienced is what appears to be a memory leak somewhere in our build process that once in a while results in the build running out of memory. Restarting the build always works though 🙂
👍 1