Gradle build phase

Is there a best practice for when to run a Gradle assemble phase?

It seems like to take advantage of caching I should run “./gradlew assemble” as a post-step in dependencies, though semantically it seems to fit better as a pre-step in the test phase.

2 Likes

You can run this step whenever it makes the most sense to you. You should still be able to take advantage of the caching no matter when you run it since the caching will take place on all subsequent builds. Does that make sense?

Hey levlaz,

Resurrecting an old thread here, but there are a couple threads about this issue and no really good answers. The problem with gradle is that it downloads dependencies on-demand, not when you call “gradle dependencies”. So with the default CircleCI approach of using “gradle test” in the test phase, any test-time dependencies will be resolved during testing, and that is after CircleCI caches the dependencies. As a result, the test dependencies are downloaded on every build.

Other threads about this issue:

https://discuss.circleci.com/t/effective-caching-for-gradle/540

There also does not seem to be a way to make gradle download all dependencies proactively. So… it seems like the best approach to using gradle on CircleCI is to run all of your commands in the “dependencies” section, or live with dependencies being downloaded on every build. :unamused:

It would be great if you could specify when dependency caching happens in circle.yml. Or, provide a shell script we could call to perform the dependency cache when we want. Or… if someone found a way to make gradle force all its dependencies to be resolved at once.

2 Likes

We put this plugin together to make it so that you can resolve all configurations (and thus their dependencies) across all projects in the build: https://plugins.gradle.org/plugin/com.palantir.configuration-resolver

Then we override the default dependencies section with ./gradlew resolveConfigurations.