Spotless Gradle plugin doesn't respect .editorconfig changes when using daemon

[0legg]

• summary of problem
  Steps to reproduce:

• enable Gradle daemon

• run ./gradlew spotlessCheck with some failing rule.

• disable said rule in .editorconfig

• run ./gradlew spotlessCheck again.

Expected: check passes.
Actual: check fails again.

Adding a --no-daemon command line parameter to second invocation resolves the issue; which hints that daemon somehow caches file contents, or doesn't treat it as an input to Gradle task.

• Gradle or Maven version
  Gradle 8.4, 8.5

• spotless version
  Spotless 6.23.1

• operating system and version
  macos Sonoma, 14.1.1

[Goooler]

Seems I've experienced this issue.

[0legg]

By some coincidence issues like #1913 were reproducible for me from time to time with daemon on, and disappeared when I explicitly turned off the daemon. It makes me think that Spotless somehow corrupts saved state.

[galiren]

Also reproduced when I changed .editorconfig indent_size from 4 to 2 and run gradlew spotlessApply, the file indent keeps exact 4 spaces. I use editorconfig with ktlint btw.

[0legg]

@Goooler Could your change in #1890 somehow affect how .editorconfig is accessed (or maybe it was always working this way)? I don't see what is triggering KtlintConfig recreation, and I bet if the daemon keeps to the old instance, the file content is frozen in memory as well.

[Goooler]

That change isn't related to this issue, I observed this issue a long time ago.

[stkent]

I ran into something that sounds like this today. I found that adding a clean (i.e. running ./gradlew clean spotlessCheck rather than ./gradlew spotlessCheck) after changes to the .editorconfig file resolved the issue for me. Perhaps task output caching logic is incorrect?

[TWiStErRob]

Just wasted another half hour on this, trying to configure ktlint, but not observing the changes.

When authoring configuration we must use gradlew spotlessApply --no-daemon. This is really inefficient in projects without configuration cache.

[madorb]

Took me quite a while yesterday to figure out that this was the reason .editorconfig changes appeared to not be taking affect.