org.gradle.tooling.BuildException: Could not execute build using connection to Gradle distribution

Must-share information (formatted with Markdown):

  • which versions are you using (SonarQube Server / Community Build, Scanner, Plugin, and any relevant extension)
  • how is SonarQube deployed: Gradle
  • what are you trying to achieve
    • Run the gradle task successfully
  • what have you tried so far to achieve this
    • So it works but only on old versions. So below is versions it worked and does not work
      • 6.3.1.5724 latest broke

        4.4.1.3373 broke

        4.3.1.3277 broke

        4.3.0.3225 broken

        4.2.1.3168 working

        3.5.0.2730 working

        3.3 working

        Note I did a review of what changed and bugs with 4.3 release
        Comparing 4.2.1.3167...4.3.0.3222 · SonarSource/sonar-scanner-gradle · GitHub

        I found from reviewing bug reports this release adds scanning of settings.gradle.kts. Note I was on latest and it was working. But then I made a change to my settings.gradle.kts and the gradle task stopped working. Will give my settings.gradle.kts

Do not share screenshots of logs – share the text itself (bonus points for being well-formatted)!

> org.gradle.tooling.BuildException: Could not execute build using connection to Gradle distribution ‘https://services.gradle.org/distributions/gradle-8.13-bin.zip’.

pluginManagement {
    repositories {
        mavenLocal()
        maven {
            val artifactory_contextUrl: String by extra
            val artifactory_repository: String by extra
            val artifactory_password: String by extra

            url = java.net.URI.create("${artifactory_contextUrl}/${artifactory_repository}")

            authentication {
                register("header", HttpHeaderAuthentication::class)
            }
            credentials(HttpHeaderCredentials::class) {
                name = "Authorization"
                value = "Bearer $artifactory_password"
            }
        }
    }
}
@Suppress("UnstableApiUsage")
dependencyResolutionManagement {
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
    repositories {
        mavenLocal()
        maven {
            val artifactory_contextUrl: String by extra
            val artifactory_repository: String by extra
            val artifactory_password: String by extra

            url = java.net.URI.create("${artifactory_contextUrl}/${artifactory_repository}")

            authentication {
                register("header", HttpHeaderAuthentication::class)
            }
            credentials(HttpHeaderCredentials::class) {
                name = "Authorization"
                value = "Bearer $artifactory_password"
            }
        }
    }
}

rootProject.name = "ProjectName"
include(":module2")
include(":module")

Hi,

Welcome to the community and thanks for this report!

We’re going to need a few more details about how analysis is broken. We could start with a --info analysis log.

The analysis / scanner log is what’s output from the analysis command. Hopefully, the log you provide - redacted as necessary - will include that command as well.

This guide will help you find them.

Also, can you share which version of SonarQube you’re scanning against?

 
Thx,
Ann

We are using SonarQube Server edition Enterprise Edition

  • Version 10.3 (build 82913)

Hi,

Your version is past EOL. You should update to either the latest version or the current LTA (long-term active version) at your earliest convenience. Your update path is:

10.3 → 2025.1.3-> 2025.4 (last step optional)

You may find these resources helpful:

If you have questions about upgrading, feel free to open a new thread for that here.

Once you’re on a current server version, if you’re still getting the analysis error, we can dig into that once you provide an analysis log.

 
Ann

Any recommendations on working through the update when everything is not on Java 17? Like my repo is but we have many.

Hi,

My biggest recommendation is to not stop at the LTA but to go all the way to the latest version: 2025.4.2, and make sure you’ve got a current version of each scanner you’re using on the build agents. That gives you JRE auto-provisioning which will let you approach your build machine/project-specific Java versions more deliberately.

 
HTH,
Ann