Ideally we'd fix our dependencies if we can. It turns out we already have https://github.com/dorongold/gradle-task-tree set up, in theory. But I spent a minute on getting the right invocation, and upgrading it from 1.5 to 4.0.0, but never did get it to give output. I did manage to get it to execute indefinitely a few times...
There are a variety of other third party plugins that can do the same, to figure out where the dependency-driven build breaks down. I've used my timebox budget on it for now, though. If you want to follow whether gradle incorporates this as a core feature: https://github.com/gradle/gradle/issues/980 Kenn On Mon, Mar 3, 2025 at 8:56 AM Danny McCormick via dev <dev@beam.apache.org> wrote: > There are a few options for turning off the cache. > > 1. The remote cache is dependent on having a cache username defined [1]. > So you could just remove that from the workflow [2]. > 2. You can explicitly disable all caching with --no-build-cache [3]. > 3. You can allow a specific task to skip the cache configurably or always > using `outputs.upToDateWhen { false }` [4][5] > > In this case, it sounds like option (3) is the best choice since you > really want something targeted for that particular task. > > Thanks, > Danny > > [1] > https://github.com/apache/beam/blob/fb061f27e264e86f7d4403997e5e4414ef148511/settings.gradle.kts#L62 > [2] > https://github.com/apache/beam/blob/3cc10eb1c47b1b8a00e22cbca07737ca77fafdd5/.github/workflows/beam_PreCommit_Java_PVR_Prism_Loopback.yml#L72 > [3] > https://docs.gradle.org/current/userguide/build_cache.html#sec:build_cache_enable > [4] > https://stackoverflow.com/questions/16154042/gradle-force-custom-task-to-always-run-no-cache > [5] > https://github.com/apache/beam/blob/fb061f27e264e86f7d4403997e5e4414ef148511/buildSrc/src/main/groovy/org/apache/beam/gradle/IoPerformanceTestUtilities.groovy#L31 > > On Fri, Feb 28, 2025 at 5:31 PM Robert Burke <lostl...@apache.org> wrote: > >> I just sent out a PR for Prism, and the java suite executed way too fast: >> >> >> https://github.com/apache/beam/actions/runs/13597430640/attempts/1?pr=34132 >> >> And when I looked it said: >> >> > Task :runners:prism:java:prismLoopbackValidatesRunnerTests FROM-CACHE >> >> which it probably shouldn't be doing for most PRs if we detected it >> should be running. >> >> PR in question: https://github.com/apache/beam/pull/34132 >> >> I don't recall seeing this before, though it's probably due to making a >> refactoring change instead of adding new behavior. >> >> Is there a way to convince gradle not to do that? Otherwise changes to >> Prism won't be properly validated against the Java suite. I thought it was >> detecting the dependency tree properly, but apparently not. >> >> Cheers, >> Robert >> >
