This message was deleted.

If you run always a “freshly” installed gradle, then it does some extra work on first run, e.g. it generates gradle-api and similar, that might take some time. I think most of the things are described here: https://github.com/gradle/gradle/issues/19565 So you might want to cache these things. Probably the easiest way is that you prepare a Docker image that has this already cached. Or you cache this (and other interesting folders from

.gradle

) to some cache if Cloud build offers it. I saw some solutions that use Cloud Storage for caching that should be relatively fast on gcloud. It could also help with dependency caching. Something similar to that maybe: https://ryanharter.com/blog/2019/02/cloud-build-recipes-saving-the-build-cache/

I just read some detailed debug logs and I think that is indeed the issue. These builds are running in a container and we use ./gradlew. This means it is created every time. I had thought that this would be a good thing as we can always generate a new ./gradlew script and not change the container when we upgrade gradle but I think we need to rethink that. Thanks!

Caching is a common problem on CI (also for other build tools). Another issue that you might see are also dependencies. Without some caching downloading dependencies might take quite some time once dependency number in project grows.

so that’s something I’m interested in also, we have a gradle remote cache working but does it cache the configuration and dependency resolution steps? these are taking a long time, (30s each). Tasks are cached relatively well now.

I've been caching `~/.gradle/caches`for my CI builds. Should I also be caching the project's

.gradle

?

Build cache doesn’t cache dependencies or configuration unfortunately. It caches just the “build results”. It might support configuration in the future

hmm, looks like this isn’t the problem. I ended up creating a build step that uses the official gradle:7.3.3-jdk11 image and just runs

gradle clean

and this took 1m44s which seems like a really long time

If gradle did not run before, it will still have to generate

gradle-api

and some some other things even if you use docker image with gradle installed. If you see something like in debug logs, it means it created gradle-api jars:

[2022-01-13 08:50:52] Generating /root/.gradle/caches/7.3.3/generated-gradle-jars/gradle-api-7.3.3.jar

You would have to cache also that in Docker image, since image you used doesn’t do that step. You can also try to run docker image with gradle installed locally and see the difference.

A build scan will let you know where the build spent it's time. scans.gradle.com

thanks all. I’m slowly going through the build step by step, trying to build a suitable docker image that has what I need but isn’t too big (since it has to be pulled by cloud build every time)