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
>
