Gradle 9 configuration-cache issue

[wakingrufus]

Is the Gradle 9 task cache supported?
When i run it with org.gradle.configuration-cache=true I get the following error

Task `:runKtlintFormatOverKotlinScripts` of type `org.jlleitschuh.gradle.ktlint.tasks.KtLintFormatTask`: cannot serialize object of type 'org.gradle.api.internal.project.DefaultProject', a subtype of 'org.gradle.api.Project', as these are not supported with the configuration cache.
  See https://docs.gradle.org/9.0.0/userguide/configuration_cache_requirements.html#config_cache:requirements:disallowed_types

Originally posted by @erkieh in #935

[wakingrufus]

@erkieh Using Gradle 9, I was able to create a buildscript like this:

plugins {
    id("org.jlleitschuh.gradle.ktlint") version "13.0.0"
    kotlin("jvm") version ("2.2.0")
}
repositories {
    mavenCentral()
}
tasks.wrapper {
    gradleVersion = "9.0.0"
    distributionType = Wrapper.DistributionType.BIN
}

with a formatting error (missing ending newline), and detect the error and run ktlintFormat to fix it, all with configuration cache enabled. So I have not been able to reproduce this. If you can create a minimal reproducer project, I can investigate further

[erkieh]

Hey,

Thanks for looking into it. It seems my build starts to fail when I add a custom filter

ktlint {
    filter {
        exclude { elem ->
            elem.file.path.contains(
                layout.buildDirectory
                    .dir("generated")
                    .get()
                    .toString(),
            )
        }
        include("**/kotlin/**")
    }
}

Here is a sample project where ./gradlew ktlintFormat fails
https://github.com/erkieh/grpc-ksp-fail

[abstratt]

Exclusion filters are evaluated during execution phase, right? If so, then custom filters need to be written with CC in mind as well.

Declaring a local val layout = project.layout should help. Something along these lines:

ktlint {
    val layout = project.layout
    filter {
        exclude { elem ->
            elem.file.path.contains(
                layout.buildDirectory
                    .dir("generated")
                    .get()
                    .toString(),
            )
        }
        include("**/kotlin/**")
    }
}

[dennisameling]

Also running into an issue with our exclude filter after upgrading to Gradle v9. The filter doesn't seem to be picked up at all. For some strange reason, when setting debug = true above it, the filter does get picked up and the build works:

ktlint {
    debug = true
    filter {
        exclude { element -> element.file.path.contains("generated") }
    }
}

Alternatively, can confirm that downgrading to Gradle 8.14.3 also fixes the filter issue without needing debug = true.

[JLLeitschuh]

Exclude and include filters are directly passed-through to Gradle, and not handled by our code in any way AFAIK. Their behavior is weird and has driven me crazy for years.

• ktlint-gradle/plugin/src/main/kotlin/org/jlleitschuh/gradle/ktlint/KtlintExtension.kt

  Lines 138 to 140 in 7fd6621

  	fun filter(filterAction: Action<PatternFilterable>) {
  	filterTargetApplier(filterAction)
  	}

• ktlint-gradle/plugin/src/main/kotlin/org/jlleitschuh/gradle/ktlint/KtlintBasePlugin.kt

  Lines 26 to 28 in 7fd6621

  	val filterTargetApplier: FilterApplier = {
  	target.tasks.withType(BaseKtLintCheckTask::class.java).configureEach(it)
  	}

So... From a technical standpoint, this:

ktlint {
    filter {
        exclude { element -> element.file.path.contains("generated") }
    }
}

Should be equivalent to this:

tasks.withType(BaseKtLintCheckTask::class.java).configureEach {
    filter {
        exclude { element -> element.file.path.contains("generated") }
    }
}

And BaseKtLintCheckTask implements the PattternFilterable interface, but just as a decorator:

• ktlint-gradle/plugin/src/main/kotlin/org/jlleitschuh/gradle/ktlint/tasks/BaseKtLintCheckTask.kt

  Lines 142 to 176 in 7fd6621

  	@Internal
  	override fun getIncludes(): MutableSet<String> = patternFilterable.includes
  	@Internal
  	override fun getExcludes(): MutableSet<String> = patternFilterable.excludes
  	override fun setIncludes(includes: MutableIterable<String>): BaseKtLintCheckTask =
  	also { patternFilterable.setIncludes(includes) }
  	override fun setExcludes(excludes: MutableIterable<String>): BaseKtLintCheckTask =
  	also { patternFilterable.setExcludes(excludes) }
  	override fun include(vararg includes: String?): BaseKtLintCheckTask =
  	also { patternFilterable.include(*includes) }
  	override fun include(includes: MutableIterable<String>): BaseKtLintCheckTask =
  	also { patternFilterable.include(includes) }
  	override fun include(includeSpec: Spec<FileTreeElement>): BaseKtLintCheckTask =
  	also { patternFilterable.include(includeSpec) }
  	override fun include(includeSpec: Closure<*>): BaseKtLintCheckTask =
  	also { patternFilterable.include(includeSpec) }
  	override fun exclude(vararg excludes: String?): BaseKtLintCheckTask =
  	also { patternFilterable.exclude(*excludes) }
  	override fun exclude(excludes: MutableIterable<String>): BaseKtLintCheckTask =
  	also { patternFilterable.exclude(excludes) }
  	override fun exclude(excludeSpec: Spec<FileTreeElement>): BaseKtLintCheckTask =
  	also { patternFilterable.exclude(excludeSpec) }
  	override fun exclude(excludeSpec: Closure<*>): BaseKtLintCheckTask =
  	also { patternFilterable.exclude(excludeSpec) }

And ultimately just configures the FileCollection the task operates on by applying the PatternFilterable API calls as lambdas to the underlying collection.

• ktlint-gradle/plugin/src/main/kotlin/org/jlleitschuh/gradle/ktlint/tasks/BaseKtLintCheckTask.kt

  Lines 103 to 109 in 7fd6621

  	@get:IgnoreEmptyDirectories
  	@get:SkipWhenEmpty
  	@get:PathSensitive(PathSensitivity.RELATIVE)
  	@get:InputFiles
  	val source: FileCollection = objectFactory
  	.fileCollection()
  	.from({ sourceFiles.asFileTree.matching(patternFilterable) })

I personally don't know why setting debug = true vs debug = false would result in different behavior. Maybe there's a caching issue here and flipping the flag invalidates the cache?

[JLLeitschuh]

Was this fixed by #962?