This message was deleted.
# cachings
Slackbot
03/24/2023, 4:37 PMThis message was deleted.
e
ephemient
03/24/2023, 4:50 PMif GitHub could resolve https://github.com/actions/toolkit/issues/505 then it would work much better for Gradle's build cache
ephemient
03/24/2023, 4:52 PMbut the current @actions/cache should already be useful for dependency caching - you're not updating those on every commit, are you?
ephemient
03/24/2023, 4:52 PMhttps://github.com/gradle/gradle-build-action is set up for that
j
Jakub Chrzanowski
03/24/2023, 5:01 PMDependencies cache is kind of useful, but on GHA it sometimes takes a lot of time to fetch — and then extract. Therefore, it sometimes takes longer to handle cache via
@actions/cacheJakub Chrzanowski
03/24/2023, 5:01 PMUnfortunately, it even leads to timeout for the whole workflow and a complete fail.
Jakub Chrzanowski
03/24/2023, 5:02 PMI wonder if
gradle/gradle-build-actionv
Vampire
03/24/2023, 5:16 PMIf you want superior handling, use the
gradle-cache-actionVampire
03/24/2023, 5:18 PMIt even supports a remote build cache backed by GHA cache, on a file-by-file basis.
r
Roldan Galan
03/25/2023, 9:18 AMDo you really need that every commit to invalidate all project’s cache in all builds?
Most probably you just need this information in the CI jobs that are publishing the artifacts, but not in the rest. If you are talking about number of commits to produce the versionCode, or you are using the sha of the head for anything, you could tweak your configuration to use fixed values in some of your CI builds (specially in the PRs, as are critically impacting developers experience).
If your build setup allows these changes, then you could get the benefit of caching on CI.