Add true configuration cache support for git commit hash #2285
+72
−36
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This prevents the configuration cache from rebuilding every single time there is a new commit, which can drastically improve build performance, especially when there are no Kotlin files changed. I tested this on pre release builds, once with no files changed that is in the build (just changing GitHub workflows) and pre release built in 38 seconds. The second time, I tried just changing an XML resource and it built in about 2 minutes. Third time changing a Kotlin file (which requires recompiling it all) and it ran in about 6 minutes, which is still drastically faster than without configuration cache at all.
There were other ways to do this, I tried numerous ways including:
Using an asset only requires merging new assets every single time which only takes about 3 seconds which is very performant and allows other gradle features aimed at speeding up build to work and allow ensuring that files that don't need rebuilding aren't. This prevents the reclaculating of configuration cache every new commit allowing it to work properly. Runtime performance seems to not be affected at all when reading the asset rather than a
resValue. Seems to have no affect at runtime.This needs to be combined with #2249 to have much impact here on the GitHub builds though.