This message was deleted.

It is cached in the project

.gradle

directory

Ah....

It should be great if the Gradle Build Action behavior would be explained with detail for those customers that are not in GitHub and have to copy it

I do sometimes wish the Gradle team had more interest in Docker. Constructing a really good Dockerfile for Gradle is surprisingly hard. Just gathering the output of all the child builds into one directory is something I had to write a custom plugin to do.

I would love to create the configuration cache without running the tasks itself to create the cc when building our Codespaces.

I would love to create the configuration cache without running the tasks itself

Does

--dry-run

not help? Or is its value a CC input aswell?

Ohhhh, I totally forgot this option, it does work, nice!

It looks like

./gradlew build --dry-run

also downloads all the necessary to do that build offline? Does that sound correct?

Not entirely. I think

--dry-run

without CC wouldn't download anything except things needed at configuration time for whatever reason - most probably bad practice. With CC enabled, providers and configurations and so on are resolved at the time the CC entry is stored, so files that are inputs of tasks most probably are downloaded with

--dry-run

and CC. But things that are only downloaded at execution time only, are still not there unless you execute that code path.

Yes, with CC, on a simple project at least, it does seem to meet my desire to separate downloading and building.

You could also have a task that iterates through the resolvable configurations and resolve them to trigger the downloads. You practically have the same requirements that people have for writing lock files.

Written that many times, but my version wasn't CC compatible and I'd very happily not have it knocking around if there's a "native" way to do it!

It should be great if the Gradle Build Action behavior would be explained with detail for those customers that are not in GitHub and have to copy it

The Gradle Build Action caching behavior is well documented quite well. Do you feel something is missing? https://github.com/gradle/gradle-build-action?tab=readme-ov-file#how-gradle-user-home-caching-works

Hey @Eric Haag! Does it mean that Gradle Build Action only caches from the Gradle user's home? No files from the project? That would break the configuration cache being cached or am I missing something?

If you look into the sources of the action, you can see that there are dedicated code paths to also preserve the configuration cache, but that the call to that logic is currently commented out. So unless the code changed since I last looked, then the configuration cache is currently not effective when using that action alone.

if you have included build you will have to add them too

So I see... if I have this setup:

/parent-project
  /child-project-1
  /child-project-2

I need to cache

/parent-project/.gradle
/parent-project/child-project-1/.gradle
/parent-project/child-project-2/.gradle

and remember to alter the cache directives in the Dockerfile when I add child-project-3 😢 I've solved this for the

build

directories by writing a plugin that copies the build dirs into

/parent-project/build/sub-projects/<tree_structure>

so I can reference them all with a single Dockerfile

COPY

. Is it possible to configure the location of the configuration-cache?

You can configure the location of

.gradle

using

org.gradle.projectcachedir

Cool, thanks!