If you are working with a Gradle build you have likely heard term cache used many times. In this post I wanted to shed some light on the type of caches that are out there.

GitHub Actions side

• GitHub Actions cache - a generic state store/restore system for any tool running on GitHub actions. Their documentation includes an example of how to handle Gradle builders (note don’t use this for your Gradle builds, see next entry)

• Gradle build action cache - a state store/restore system for Gradle runs on GitHub actions, that works a lot better than the generic GitHub cache action. It is maintained by Gradle itself. You should be using this if you use GitHub Actions.

Gradle build tool side

• Gradle configuration cache - Gradle feature to store/restore the state of the configuration phase that you likely know from your terminal as:

  <-------------> 0% CONFIGURING [4s]
  

  Gradle serializes all the tasks with all the inputs that might invalidate how the task is set up during the first run, and for the later runs it reloads these from disk instead of rebuilding the whole task graph again, essentially making it so that ./gradlew test on the second run only run the tests skipping the step of figuring out how to configure this task. This feature is currently (as of April 2022) incubating, but it works well and should be adopted.

• Gradle local build cache - a mechanism to skip Gradle task execution phase by storing/restoring outputs for a given input state to disk. For example, if you run a cacheable task, detete the build/ directory, and then run the task again, Gradle will skip running it and just directly restore the output from the first task. This is in particular helpful when switching between branches. This feature is stable, but sadly off by default, you should be adopting it

• Gradle remote build cache - a feature equivallent to local build cache except using a remote server to store task inputs/outputs instead of local disk. This type of cache is often used by having Continious Integration (CI) builder pushing to this server, and all the local developers reading this cache. You can set this up using Gradle Enterprise, Gradle Cache Node, AWS S3 or GCP storage buckets.

• GRADLE_USER_HOME - a directory (by default ~/.gradle) that Gradle uses to store various non-project specific global state, including Gradle wrapper cache (extracted gradle-X.X-bin.zip) and artifact cache (to avoid redownloading maven dependencies)

• Android Studio cache - the infamous Invalidate Caches / Restart that solves all of your Studio problems. This is in fact does not touch any of the Gradle caches, instead it clears various Intellij state like indexes.