How to clear build cache for a specific task?

(Róbert Papp) #1

We have a project with many modules in Kotlin Android project, for simplicity let’s say
project(':b').dependencies.implementation project(':a')

When we build, we get

Task ':a:compileDebugKotlin' FROM-CACHE
Task ':b:compileDebugKotlin' FAILED
e: ....kt: (17, 13): Cannot find a parameter with this name: id
e: ....kt: (21, 22): Type mismatch: inferred type is String? but String was expected
e: ....kt: (26, 9): No value passed for parameter 'type'

where a property named id was renamed to type and a constructor parameter’s type has changed. (The code compiles for those who didn’t have the previous version checked out)

We tried running :a:cleanCompileDebugKotlin, running project-wide clean, deleting .gradle folder in the project, deleting the affected build folders, deleting some ~/.gradle/caches/subfolders. Nothing helped, the compilation problem still persisted.

The only thing that helped is running gradlew --no-build-cache clean assembleDebug once.

Is there a way to clean (or force-refresh) a specific task’s or subproject’s build cache only instead of a full re-build?
gradlew :a:clean a:assembleDebug :b:clean :b:assembleDebug --no-build-cache
is what I would’ve expected to work.

(Tony Robalik) #2

I tried reproducing this on a sample build and could not. Could you reproduce this in a minimal project you could share publicly?

(Róbert Papp) #3

Hey @autonomousapps, I know it’s not easily reproducible, only happened two times for us, but when it happens it comes with a vengeance and usual “clean/clear” operations don’t help, even heavy duty ones where we delete half the ~/.gradle folder; only the above full clean and and no-cache build helped.

We have a known commit where if you do git checkout a; gradlew; git checkout b; gradlew this will repro, but can’t share our full codebase for obvious reasons. If I find time I may try to reduce to a minimal example, but until then I’m just simply asking how to clean a single task/subproject’s build cache? (similar to how it’s possible to :subproj:cleanSomeTask and :subproj:clean)

What I want to know is if a task says FROM-CACHE, how do I make it forcefully rebuild and run the actual task operations without reading any cached state and only using the real input files and build folder intermediate files?

(Tony Robalik) #4

What seems to be happening here is that there is some missing input to the task(s) in question, which means the build cache is serving you incorrect artifacts.

I suggest the following next steps:

  1. The next time your build fails in this way, publish a build scan from it. If you don’t have build scans enabled for all builds, you can publish the scan from the most recent build with the buildScanPublishPrevious task. See here for more documentation on publishing build scans. Once published, save the link to that scan.
  2. Now, re-run the build with --no-build-cache --scan. This will disable the build cache and publish a scan. Save the link.
  3. Reply to this message with both scans.

(Tony Robalik) #5

@TWiStErRob I realized I didn’t actually answer your direct question, so here goes.

Unfortunately, there is no way to do what you want. We provide no support whatsoever for deleting the cache on a per-task basis.

That said, you have two options for improving your situation right now.

  1. You could disable caching for the KotlinCompile task (elaborated on below)
  2. You could disable the build cache entirely.

To disable the build cache for KotlinCompile, you would add the following:

tasks.withType(org.jetbrains.kotlin.gradle.tasks.KotlinCompile) { 
    outputs.cacheIf { false } 

Of course, that would only apply to the project you added the code block to. To add this to all subprojects/gradle modules in your project, add this to your root build.gradle:

subprojects {
    tasks.withType(org.jetbrains.kotlin.gradle.tasks.KotlinCompile) { 
        outputs.cacheIf { false } 

(FYI, I only know the fully-qualified name of that class because build scans told me so :wink: . I also used build scans to verify this solution does in fact disable caching for all tasks of that type.)