This message was deleted.

The plugin used for generating avro files is the following: https://github.com/davidmc24/gradle-avro-plugin Is there any workflow that you guys can think of that could potentially cause this to happen?

look at the task from that plugin that generates the files you want and takes the .avdl input you're talking about and look for obvious issues first. build scans can help. If you are a GE customer, you can do a build comparison between failed and successful builds

Yes, from time to time it happens that the Grand state gets confused. It then thinks tasks are up-to-date even though they are not, leading to very unexpected behavior.

@Vampire is there a solution for this? I’m thinking of maybe purging our caches on GitLab runners at midnight and running a full build afterwards

It happened occasionally here and I did not find any clue as to what is wrong or how to reproduce. If I see it happen, I usually just delete

<GRADLE_USER_HOME>/*

and

<root project>/.gradle

and then it works again. But that's just the mega-hammer to get the colleague up and running again quickly.

I haven’t been able to reproduce it either. I think I’ll purge the cache on my runners on the weekend so that I can have some proactivity. Glad to know I’m not the only one, thanks for your insights

Actually, I've never seen it on CI, but that's probably caused by me only running clean builds on there as on CI I prefer reliability over speed. 🙂

Interesting, we actually opted against running

clean

on CI.

Well, like always, every decision has its pros and cons 🙂

our CI costs would spiral out of control if we didn't use build cache in that environment. it's absolutely critical

Quite possible, we have TeamCity on-premise, so costs do not really differ. And besides that, I more meant incremental building. Reusing a build-cache created from a clean build should imho be fine regarding reliability.

I see this statement in https://docs.gradle.org/current/userguide/common_caching_problems.html which is pretty much the issue we’re having but there’s no solution for it on that page. Are there any cons to purging our Gradle cache in our runners at midnight and attempting to rebuild a “clean” cache promptly afterwards? I’m considering it to be a silver bullet

The solution to that described problem is, to not implement buggy tasks, or not use buggy tasks, or at least work-around-fix them by adding the inputs it uses. In the cases I meant the tasks implementations are fine though.