This message was deleted.

Afaik no, a task is directly put to cache when it successfully finished. Maybe

kapt

should not be successful in those cases?

gotcha, the thing is the build is cancelled, it doesn't fail. If we let it proceed, it will build successfully. But, the new commit pushed up to the PR eagerly cancels the current running CI build. We hypothesize that we'll run into this issue even if we turn off eagerly cancellations because it's a timing issue with the cache. Only solution we see is postponing cache writes to the end or disabling caching for

kapt

but that has major build time implications

Actually, to me it sounds like a Gradle bug if it indeed is like you describe.

We have had two instances the past week where someone on our team adds a new empty gradle module to the project (build.gradle + settings.gradle changes). • They open a PR • Push up a new commit for format fix or something simple • original CI build gets cancelled • new commit CI build runs •

kapt

failures for the main

assemble

task • rename the new module • cache entries are invalidated • green CI The reason renaming the module works is because we're using

TYPESAFE_PROJECT_ACCESSORS

and according to this, they contribute to classpath of all buildscripts

As I said, sounds like a bug to me. Either a

kapt

but for not defining its inputs and outputs properly, or a Gradle bug for writing cache entries when it shouldn't.