Gradle run fails with configuration cache being enabled

Must-share information (formatted with Markdown):

  • which versions are you using: SQ Gradle plugin, SQ server 9.9.4
  • how is SonarQube deployed: I guess via an Azure DevOps task, not sure
  • what are you trying to achieve: Have gradle configuration caching enabled
  • what have you tried so far to achieve this: Log warnings, disable configuration caching

To me it seems exactly like Sonar Plugin fails when configuration cache is enabled but I was asked to post a new thread :slight_smile:.

Part of the Azure DevOps pipeline:

          # Prepare SonarQube Analysis
          - task: SonarQubePrepare@5
              SonarQube: "SonarQube" # Name of the service connection
              scannerMode: "Other" # Needed for Maven / Gradle integration
              extraProperties: |
                sonar.projectKey=${{ variables.sonarProjectKey }}
              # projectKey enables PR Decoration
              # Other properties configure the test coverage and exclusions

          - task: Gradle@3
            displayName: 'gradlew envIntegrationDebug'
              gradleWrapperFile: 'gradlew'
              options: '--build-cache -Dorg.gradle.internal.http.socketTimeout=60000 -Dorg.gradle.internal.http.connectionTimeout=60000 --configuration-cache-problems=warn'
              tasks: 'assembleBrandB2CEnvIntegrationDebug testBrandB2CEnvIntegrationDebugUnitTestCoverage'
              publishJUnitResults: false
              # Sonar Analysis parameters
              sonarQubeRunAnalysis: true
              sqGradlePluginVersionChoice: "specify"
              sonarQubeGradlePluginVersion: "" #

          # Publish SonarQube Quality Gates to Azure DevOps
          - task: SonarQubePublish@5
              pollingTimeoutSec: "300"

Error logs:

/__w/49/s/gradlew --build-cache -Dorg.gradle.internal.http.socketTimeout=60000 -Dorg.gradle.internal.http.connectionTimeout=60000 --configuration-cache-problems=warn assembleBrandB2CEnvIntegrationDebug testBrandB2CEnvIntegrationDebugUnitTestCoverage -I /__w/_tasks/Gradle_8d8eebd8-2b94-4c97-85af-839254cc6da4/3.231.2/node_modules/azure-pipelines-tasks-codeanalysis-common/sonar.gradle sonarqube
Starting a Gradle Daemon, 1 incompatible and 1 stopped Daemons could not be reused, use --status for details
Calculating task graph as no cached configuration is available for tasks: assembleBrandB2CEnvIntegrationDebug testBrandB2CEnvIntegrationDebugUnitTestCoverage sonarqube

1 problem was found storing the configuration cache.
- Task `:sonarqube` of type `org.sonarqube.gradle.SonarTask`: error writing value of type 'org.gradle.api.internal.provider.DefaultMapProperty'

See the complete report at file:///__w/49/s/build/reports/configuration-cache/41v2p3ldrgxfmbf6tzhc7jpin/cgk2d88eitub6i6346x5rspyo/configuration-cache-report.html

FAILURE: Build failed with an exception.

* What went wrong:
Could not load the value of field `properties` of task `:sonarqube` of type `org.sonarqube.gradle.SonarTask`.
> Unexpected provider value

With this, it does get built:
options: '--build-cache -Dorg.gradle.internal.http.socketTimeout=60000 -Dorg.gradle.internal.http.connectionTimeout=60000 --no-configuration-cache'


Could you please run sonar task with --info and --stacktrace options so we can see the full stack trace of the error?

Meanwhile, note that the configuration cache is not yet properly supported by the sonar task, so we need full logs to understand how we can help you.


Hi, I’ve run it with --stacktrace: log.txt · GitHub

Hello @carstenhag,

From the logs I can see that there should be a configuration cache report here:

Could you, please, share it with me, as it looks like te stacktrace is not helpful.


Thanks, was able to find more useful information there: sqlogs · GitHub

It seems related to using libaddressinput (libaddressinput/common/src/main/java/com/google/i18n/addressinput/common at master · google/libaddressinput · GitHub) in the project. When building locally, I don’t have any issues even with configuration caching enabled.
The exception is caused by the sonarqube plugin, so I guess it has to be fixed there?

Hey @carstenhag,

Thanks for the logs. I looked there and I don’t think we can solve the root cause in sonarqube scanner as it seems to be indeed related to a missing jar: File/directory does not exist: /__w/15/s/libaddressinput/build/libs/libaddressinput.jar

Just a random guess: maybe some local/remote cache is corrupted; maybe you can try to clean up the cache?

If you manage to create a local reproducer I can try to debug the issue deeper with the reproducer and the Sonar Gradle plugin.