Using withToolingApiUsingModulesCaching in rewrite-gradle tests

[greg-at-moderne]

What's changed?

Using withToolingApiUsingModulesCaching added in openrewrite/rewrite-gradle-tooling-model#33.
Following the advice by @shanman190 at: #4965 (comment)

What's your motivation?

To speed up CI in this project, specifically the duration of rewrite-gradle tests.

EDIT: Adding some non-scientific measurements:

What	Without this change	With this change
./gradlew rewrite-gradle:test on my laptop	13m 18s	2m 6s
CI on some other PR touching rewrite-gradle only	some PR a few days ago: 9m 43s	this PR: 8m 21s
CI on a PR without this change touching rewrite-core	19m 17s	17m 59s

(So it seems like the biggest win is for people living far away from Maven Central servers in terms of network latency)

[knutwannheden]

Looks promising. What difference does that make when running a clean build?

[shanman190]

@greg-at-moderne, the reason that the options exist are because within the CI context and iterating quickly, you want to be able to pick up the latest dynamic version for latest.integration for rewrite-maven or the org.openrewrite.gradle.tooling:plugin quickly -- which by the way these two options only come into play when pulling from remotely deployed artifacts. When dynamic (latest.release, latest.integration) or changing (1.0-SNAPSHOT) dependencies are in use by default, Gradle will cache these for 24 hours. In OpenRewrite, the snapshots are always used and integrated together rapidly with each other. You can see the same thing being done for all of the top-level OpenRewrite projects via the shared binary build plugin openrewrite/rewrite-build-gradle-plugin.

So whether you're developing on a core module, the Gradle tooling API, or one of the OSS build plugin, you're getting the latest snapshot versions for everything. It sounds like in your context, you're a little further from one of the Maven Central repositories, so you're experiencing increased latency as a result of these options under all of the above contexts. It may be that you're using the Intellij runner for most activities, which given it bypasses Gradle often, would result in you not feeling the impact of the core module variation conveniently. But when here in rewrite-gradle, it's directly in front of you resulting in being felt early and often.

@jkschneider & @sambsnyd, maybe we've reached a point where a value of 0.seconds is now becoming a pain point and should be revaluated within the additional data?

EDIT: this is also why Gradle has the --refresh-dependencies option to invalidate the cache entries and force a dependency refresh.

EDIT 2: we can also use Develocity to measure just how much of an impact it is before and after from different contexts and physical locations.

[greg-at-moderne]

from different contexts and physical locations.

IMHO, our CI running in Github Actions should be the top criterion. I've included my laptop just for the context.

[shanman190]

Gotcha! Good context to know. I'll do some research into optimizing the build based upon the GHA build scans.