From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

Hey folks, I am trying to re-implement what <https://github.com/gradle/actions/tree/main/setup-gradle|actions/setup-gradle> does but with GCP buckets, and am noticing that when I cache the following folders within `~/.gradle/cache`, it ends up skipping tests when running `./gradlew testDevDebugUnitTest` for an Android project (even though I did make changes to one of the gradle modules). The folders i'm caching are `8.10.2`, `build-cache-1`, `jars-9`, and `modules-2`. Is this the expected behavior when caching this across runs on Github? (It's the same task and the same CI runner).

Looking at logs, it says `Task :features:nameOfFeature:testDevDebugUnitTest FROM-CACHE` .

seems like gradle is more than likely doing the right thing based on task inputs. work avoidance at its finest I'd say.

Maybe with `-Dorg.gradle.caching.debug=true` you get more information about how the cache key is built and why it might not have changed as expected

Yeah I did update kotlin files in the classpath of that module. Thanks! I will try with debugging to see.

was it cached because of where the changed code was in terms of api/impl in your dependency graph? or does test task config treat that differently than compile tasks? I assumed it treats it the same as compile

Compile should use `@CompileClasspath` as only the public API is relevant

Test executes the code, so should use `@Classpath` which eradicates some irrelevant things like timestamps in the jars and so on, but for running the implementation is relevant so should not be ignored

That's also why you sometimes use "runtime classpath normalization" feature for example to define that property "version" properties file "X.properties" does not change the result so should be ignored for the fingerprinting

yeah that makes sense to me too I guess. So I'd expect some sort of custom gradle logic is messing it up somewhere? either that or a bad assumption somewhere else. (file we thought should of triggered the test run actually isn't in the given tests classpath)

Hmm, I added some additional logging and can't seem to repro it anymore. I'll keep an eye out and can update this thread if it happens again. Thanks for the tip on debug cache logs!