This issue is somewhat related to the following issues, but not the same:
- Sonar Plugin fails when configuration cache is enabled
- Gradle run fails with configuration cache being enabled
- Gradle Scanner is incompatible with upcoming configuration cache
In version 3.5, the SonarScanner for Gradle plugin implemented a change that marks the sonar task as incompatible with the Configuration Cache:
However, quoting from the release notes of Gradle 9.0.0:
Configuration Cache entry is now always discarded for incompatible tasks in warning mode
Configuration Cache enables gradual migration by allowing to explicitly mark tasks as incompatible. When incompatible tasks are scheduled for execution, cache entry is not stored and tasks do not run in parallel to ensure correctness. Configuration Cache can also run in the warning mode by enabling org.gradle.configuration-cache.problems=warn, which hides problems and allows storing and loading of the cache entry, running tasks in parallel with potential issues. The warning mode exists as a migration and troubleshooting aid and is not intended as a persistent way of ignoring incompatibilities.
Starting with Gradle 9.0.0, the presence of incompatible tasks in the work graph results in the cache entry being discarded regardless of the warning mode to ensure correctness. If you relied on the warning mode previously, consider marking the offending tasks as incompatible instead. However, at this stage of Configuration Cache maturity and ecosystem adoption, we recommend resolving the incompatibilities instead to ensure performance benefits this feature brings.
So the bottom line is, marking a task as incompatible is supposed to be a temporary solution. Now with the first release of major version 9, Gradle got stricter, and even though previously we chould just set org.gradle.configuration-cache.problems=warn and hide the issue that a task in incompatible, this is no more. This flag now doesn’t seem to do anything different for tasks marked as incompatible, the problem is reported anyway, and the configuration cache is discarded for the build executions involving the sonar task.
I think now it’s important to go through the Configuration Cache requirements, and make sure they are followed by the plugin.
While the configuration cache is the preferred behavior for Gradle 9, Gradle 10 will want to make the configuration cache the default behavior, so it would be really beneficial for us if you could make the SonarScanner for Gradle plugin compatible.
Thanks in advance.