Is there a way to share the configuration cache in a CI situation?

It can be tricky to get it working but if you are in GHA, I'd say start by making sure you use the setup action and configure it with an encryption secret. https://github.com/gradle/actions/blob/main/docs/setup-gradle.md#saving-configuration-cache-data

Thanks - I'm sometimes in GHA, but more in a Dockerfile

more or less you just need to ensure that the gradle user home directory is saved/restored around the build. Make sure you archive the config cache report files in whatever environment you are running so you are not chasing ghosts too much while debugging misses

I've experimented with this:

RUN --mount=type=cache,target=$work_dir/.gradle/configuration-cache \
    ./gradlew build

but that means the directory is shared between concurrent builds. We saw some odd build failures, and given I was told not to share

~/.gradle/caches/build-cache-1

like that but use a remote build cache instead, I suspect that just using a cache mount for

$work_dir/.gradle/configuration-cache

is also bad practice?

I expect that should be a fine way to do it so long as multiple gradle builds are not trying to use the same mount concurrently. Though I don't know for sure if only that directory is required. I used to do a similar thing with the docker-layer-cache in CircleCI before they reworked the feature. Previously it would behave like an EFS volume mounted to the VM, then they changed it to be a more typical S3 zip file save/restore and the time overhead made the cache savings moot since it added so much time in setup/teardown.

That's the point, he does run builds in parallel that would use it in parallel. And yes, I think also here - and everywhere else in

.gradle

it is a bad idea to do so. The Gradle User Home is simply not designed to be used by different processes that cannot talk to each other and I'm not aware of anything inside that is assumed to be used concurrently from builds that cannot communicate. And also, sharing that directory is by far not enough to reuse CC entries. Quite the opposite, you will reuse CC entries that are incomplete because they point to downloaded dependencies, artifact transform results, and so on, which then all are not present. Besides that the CC entries probably not get reused at all without supplying the same encryption key to all builds. But if you would, then it would fail when it tries to reuse the CC entries. If you want to reuse CC on different machines, you most probably need to replicate what the official GitHub action is doing, saving many things from the

GRADLE_USER_HOME

to some cache facility and restoring it before run, but not using the directories concurrently.

Thanks all

I managed to setup a stable solution referring to this article https://www.jasonpearson.dev/gradle-config-cache-reuse-on-ci/ It’s written vaguely so I had to fill-in the gaps with actually implementing it. So it’s not impossible and can be worth it.