This message was deleted.

Your initial thinking is correct - simply using gradle-build-action enables caching with no additional configuration required. That will cache the Gradle distribution, downloaded dependencies, and a few other tidbits.

Does the action really enable the build output cache by default? I wouldn't have expected that.

The github build action is unrelated to org.gradle.caching.

So yes, he has to enable the build output cache for his project either by commandline option, or by configuring it in

gradle.properties

, even when using that action, right?

that is correct, if build output caching is desired. Even without that the Gradle build action will cache the Gradle distribution, dependencies, generated JARs, etc.

Thanks, I will try it!

If you go with https://github.com/burrunan/gradle-cache-action, they you’ll get Gradle Build Cache service backed by GitHub cache, and incremental dependency cache (=PR builds could reuse cache from main branch + delta)

But still only if enabled for that specific build, not enabled by default, or?

I think it adds

buildCache

configuration by default

It adds a build cache configuration for remote build cache that is backed granularly by the GHA cache facility, yes. But still this will only be used if Gradle build cache is actually enabled for a build.

By default, the action enables the

local

build cache, and it adds a remote build cache that stores the data in GitHub Actions cache

So if you merely apply the action, then it would enable build cache.

The README indicates one needs to enable the build cache:

This is how you can enable local build cache (don’t forget to add

--build-cache

option or

org.gradle.caching=true

property):

```// settings.gradle.kts

val isCiServer = System.getenv().containsKey("CI")

// Cache build artifacts, so expensive operations do not need to be re-computed

buildCache {

local {

isEnabled = !isCiServer

}

}```

The README indicates one needs to enable the build cache

It is in case you want to enable caching when building the project locally

Confusing. How is that relevant to a GitHub action?

it is not completely relevant, however, it is a way to promote Gradle Build Cache feature. I guess it is under-used one

Would suggest rewording to make it clear what applies to a non-CI build.

With

gradle-build-action

the cache is only written to from your repo's default branch by default

Ah, right, then I remembered wrongly about the default cache. The readme does not really contradict. It shows how to disable the local build cache on CI but enable it on local builds and remindes that you need to enable the cache using argument or Gradle property when running local builds. On CI with ephemeral agents the local cache only makes sense if you run multiple Gradle builds within the same action that could reuse things from the cache, otherwise it is just a waste of time.

@Vampire doesn't the GitHub action copy the local cache from previous runs (on a default branch) into each ephemeral runner?

Does it? Well then, dunno why you should disable it on CI

You could switch it off to save cache space and then disable the local cache

The behavior should be sane: it should not do dumb things by default, so disabling things at random is not the best option. If it does dumb things by default, then it is better to file a bug. The switches are there to fine-tune in case of weird requirements/issues.

Mind telling us then, why the documentation example suggests to disable the local build cache on CI? 🙂

I can’t tell right now, so I filed https://github.com/burrunan/gradle-cache-action/issues/57

Btw. while we are at it, did you also consider pros and cons regarding the official

gradle-build-action

? In the readme there is only a comparison to

gradle-command-action

. For example as far as I know your action does not support caching the configuration cache yet while the official does. 🙂

To be fair, the key difference is that

burrunan/gradle-cache-action

is not endorsed by Gradle, so I am afraid it will not get traction. Just like JCenter died, because “Maven Central” was always “the official” repository, so JCenter had doomed to be the second level citizen. I believe

gradle/gradle-build-action

misses: • remote build cache, including multi-cache when you fetch from GitHub Actions cache, and the remote build cache configured in the project • Incremental file-based cache storage.

burrunan/gradle-cache-action

implements incremental storage for file-based caches (e.g. in case

build cache

is disabled) • Maven repository caching. For instance, if your build uses Maven-based builds as prerequisite, then you might want to cache

.m2/

as well. Of course, it is incremental, and subsequent PR-based builds can reuse “main cache + previous PR cache” • Build error propagation from the log to file diff UI: https://github.com/pgjdbc/pgjdbc/pull/2720/files#file-pgjdbc-src-main-java-org-postgresql-package-info-java-L6 • Build scan is not surfaced. For instance, with

burrunan/gradle-cache-action

, the links are easier to use: https://github.com/pgjdbc/pgjdbc/actions/runs/3929085356 • Kotlin.

gradle/gradle-build-action

is TypeScript-based while

burrunan/gradle-cache-action

is Kotlin-based There might be other minor differences

Would probably make sense to add that to the readme too. 🙂 I'm for sure not the only one wondering and without guidance on the differences, I'd probably also prefer the official action if I were not already using your action from the time when the official action did not exist yet.