configure-local-build-caching.gradle should also disable the Develocity remote build cache

Summary

components/scripts/gradle/gradle-init-scripts/configure-local-build-caching.gradle is intended to disable any configured remote build cache so experiments 2 and 3 validate local cacheability in a closed system. The current implementation only neutralises HttpBuildCache:

settingsEvaluated { settings ->
    settings.buildCache {
        local {
            enabled = true
            push = true
            directory = new File(expDir, 'build-cache')
        }
        remote(HttpBuildCache) {
            enabled = false
        }
    }
}

remote(HttpBuildCache) { enabled = false } registers a disabled HttpBuildCache as the remote, which only matches the generic org.gradle.caching.http.HttpBuildCache class. Projects that wire their remote cache through the Develocity plugin — i.e., buildCache { remote(develocity.buildCache) { server = '…' } } in settings.gradle — register a different class (com.gradle.develocity.agent.gradle.buildcache.DevelocityBuildCache). The HttpBuildCache substitution doesn't reach those, so the Develocity remote stays active for the duration of the experiment.

Reproduction

1. Take any project that wires its remote cache through the Develocity plugin (e.g., buildCache { remote(develocity.buildCache) { server = '…' } } in settings.gradle), with a Develocity access key in the environment.
2. Run 03-validate-local-build-caching-different-locations.sh.
3. During either experiment build, observe settings.buildCache.remote — it's still the DevelocityBuildCache instance, enabled = true.
4. If the project also enables remote push (e.g., via the io.spring.develocity.conventions plugin, which calls remote.enablePush() when an access key and CI indicator are present), the experiment writes to and reads from the configured remote backend.

Impact

When the configured remote cache stays active, exp 2/3 no longer measure local cacheability in isolation — they measure a hybrid local+remote system. Cache hits coming from the remote backend can be misattributed to local caching, masking actual local-cache misses. We hit this concretely while running cacheability-validation experiments back-to-back: an earlier experiment's writes were being read back by a later one's "fresh" second build, contaminating results across iterations of the same session.

Common project shapes affected:

• Micrometer (buildCache { remote(develocity.buildCache) { server = 'https://ge.micrometer.io' } })
• Caffeine (similar via gradle/develocity.gradle)
• Anything using io.spring.develocity.conventions (enables both the Develocity cache and push under CI)
• Any project using develocity { buildCache { … } } or buildCache { remote(develocity.buildCache) { … } }

Source

Discovered while investigating gradle/dv#66060 (BCO eval failures on cacheability-validation experiments against Develocity-configured projects).

Start with components/scripts/gradle/gradle-init-scripts/configure-local-build-caching.gradle and inspect how settings.buildCache configures the local and remote caches. Reproduce with a project using buildCache { remote(develocity.buildCache) } and run 03-validate-local-build-caching-different-locations.sh. Done means experiments 2 and 3 no longer read from or write to the configured Develocity remote cache.