SonarScanner for Gradle does not support the Configuration Cache

SonarQube Server / Community Build
,
1

This issue is somewhat related to the following issues, but not the same:

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.

2 Likes
3

Could you please share the issue that occurs? If the “notCompatibleWithConfigurationCache” marker is removed from the Sonar task, nothing appears to break.

4

The problem is, Gradle 9 changed the way marking a task as notCompatibleWithConfigurationCache has an effect on the Configuration Cache:

  • Problems will still be reported.
  • There is no best-effort manner to keep the cache entry stored anymore. The cache entry will always be discarded.

So yes, regardless of how you set the org.gradle.configuration-cache.problems flag, your solution is not a solution anymore, it doesn’t do anything except breaks the Configuration Cache in Gradle 9. The reason is, this marker was supposed to be a temporary solution.

So please, remove that marker, and make the task actually compatible with the Configuration Cache, because losing that feature will also come with the consequence of losing other features that are related to it, like inter-project task parallelism, and in the future, when Project Isolation becomes stable, we’ll also lose parallel project configuration.

Edit: If you remove the marker, then the the user has to set the org.gradle.configuration-cache.problems to warn in order to prevent the build from failing when the Configuration Cache is enabled. The cache entry will be stored in a best-effort manner with problems reported. However, “best effort” means there is a potential that this will introduce a bug.

I don’t have any issue to share, because this change is a feature of Gradle, and I linked the release notes.

Thanks again for considering!

1 Like