https://gradle.com/ logo
Join Slack
Powered by
Is this still the recommended approach for caching...
# community-support
c
Is this still the recommended approach for caching various gradle artifacts? https://cookbook.gradle.org/ci/gitlab-ci/#enable-caching
Copy code
build-gradle-project:
  # …existing configuration…

  variables:
    GRADLE_USER_HOME: $CI_PROJECT_DIR/.gradle

  cache:
    paths:
      - .gradle/wrapper
iirc the .gradle directory in a project also contains its own set of files, are they guaranteed not to conflict?
v
"various"? The only thing that config is caching, is the Gradle distributions downloaded by the Gradle wrapper.
Besides that, the document was created 1 year ago, so I guess not too much has changed since then. 🤷‍♂️
If you are concerned about potential clashes, you could also change the 
gradle-wrapper.properties
instead. It defines where to store the zip and dist. The base by default is 
GRADLE_USER_HOME
but could also be 
PROJECT
.
c
So for example at the end of our build the folder contains
Copy code
ls $GRADLE_USER_HOME
8.6
buildOutputCleanup
caches
daemon
jdks
kotlin
kotlin-profile
native
notifications
vcs-1
Right, that exact config is only caching the wrapper, I'm wondering what else is safe/sane to cache.
v
According to that cookbook nothing it seems 😄
Besides that, I would probably look at what and how the Gradle GitHub Action caches and replicate that. 🤷‍♂️
c
It's been a while since I've checkout out their github actions
v
They even support configuration cache as long as the environment is identical and an encryption key is set.
c
Our mono repo is unfortunately not quite ready for cc in ci. We'll get there eventually 😮‍💨
e
Open in Slack
PreviousNext
Powered by