👋 I'm using the maven develocity plugin on the apache james project. We recently had an issue on CI where the remote build cache ended up being corrupted. I managed to build a reproduction flow which reliably demonstrated the cache corruption on the local cache. After upgrading the plugin version I was able to observe that the corruption did not occur anymore. However running the build on the CI with

-DrerunGoals

did not fix the remote cache (but it did rerun all the cacheable tasks) reverting the flag from the projects Jenkinsfile triggered the same error again. I'm wondering if this is expected. Maybe because of the way I passed the

-DrerunGoals

through environment variables it was somehow included in the cache key and it didn't overwrite the corrupted remote cache entries The documentation about

DrerunGoals

is pretty light and could probably benefit from a bit more precision on what to expect and possible pitfalls when used on CI envs ...

Hi, @Jean Helou 👋🏻 Could you share the build scan in which

-DrerunGoals

was applied but did not re-store in your remote cache? Other build scans of the points you mentioned would also be helpful (e.g. after you reverted the flag). That’ll let me understand the issue better. I'd be happy to propose a documentation change internally.

arg I didn't capture things properly so I can't show exactly what happened : branch state has been GCed, jenkins build history has been trucated which leaves me only with build scans but I can't prove what I'm saying below is 100% right initial state • build (scan) • stable tests (scan) the run with -DrerunGoals • build (scan) • stable tests (scan) the run after -DrerunGoals • build (scan) • stable tests (scan) as far as I can remember between the run with -DrerunGoals, all I did was remove the flag from the jenkins file but I can't prove it T_T

A few facts here: •

-DrerunGoals

will not modify the cache keys • Local cache entries take precedence for cache hits over remote entries • Cache keys are independent of the local and remote caches, so the functional test you ran should not care which cache it is using • Cache entries are mutable—if you store a cache entry with a certain key, but the cache entry is different, the newer entry will be stored Given that, I wonder if it is possible that you: 1. Ran a build on

jenkins host 1

which wrote a corrupt cache entry to both the local and remote caches 2. Ran a build on

jenkins host 2

with

-DrerunGoals

that wrote the the "correct" cache entry to both the local and remote caches 3. Ran a build on

jenkins host 1

which got a cache hit on the corrupt cache entry that was located in its local cache

hmm we disable local cache on CI