SonarSource/sonarqube · error · GradleException

sonar.properties file by default must not provide any user c

Error message

sonar.properties file by default must not provide any user configuration.

What it means

The verifySonarProperties task checks that the packaged default conf/sonar.properties in sonar-application contains only comments and blank lines. SonarQube ships a clean default config; any uncommented user setting in that source file aborts the build with this GradleException.

Source

Thrown at sonar-application/build.gradle:101

    jdbc_mssql 'com.microsoft.sqlserver:mssql-jdbc'
    jdbc_mssql_entra 'com.microsoft.azure:msal4j'
    jdbc_postgresql 'org.postgresql:postgresql'

    webapp 'org.sonarsource.sonarqube:webapp-assets'

}

// declare dependencies in configuration bundledPlugin to be packaged in lib/extensions
apply from: 'bundled_plugins.gradle'

//verify if sonar.properties files does not have any external input
task verifySonarProperties(type: Verify) {
  def propertiesFile = file('src/main/assembly/conf/sonar.properties')
  propertiesFile.withReader { reader ->
    def line
    while ((line = reader.readLine()) != null) {
      if (!line.startsWith('#') && !line.isEmpty()) {
        throw new GradleException('sonar.properties file by default must not provide any user configuration.')
      }
    }
  }
}


tasks.register('generateLicenseReport', WriteDependencyLicensesTask) {
  configurationName = 'appLicenses'
  outputDir = layout.buildDirectory.dir('reports/dependency-license')
}

tasks.register('downloadJres') {
  inputs.file(layout.projectDirectory.dir('src/main/resources/jres-metadata.json').asFile).withPathSensitivity(PathSensitivity.RELATIVE)
  outputs.dir(layout.buildDirectory.file('jres'))
  outputs.cacheIf { true }

  doFirst {
    // Clean the output directory before downloading so stale JREs from previous versions don't accumulate.

View on GitHub (pinned to 184c821202)

Solutions

Revert sonar.properties to comments-only: prefix any active setting with '#'
Test configuration on your installed instance's conf/sonar.properties, not the packaged template
If a default must change intentionally, update the verification task/build expectations deliberately, keeping the shipped file commented

Example fix

// before (sonar.properties)
sonar.web.port=9001
// after (sonar.properties)
#sonar.web.port=9001

Defensive patterns

Strategy: validation

Validate before calling

// shell: fail fast if shipped sonar.properties has active lines
grep -vE '^\s*(#|$)' sonar-application/src/main/assembly/conf/sonar.properties \
  && { echo "sonar.properties must contain only comments"; exit 1; } || true

Prevention

Never uncomment lines in the packaged conf/sonar.properties template
Configure real instances via their own conf/sonar.properties, not the source template
Review diffs to sonar.properties before committing — every line must start with '#' or be empty

When it happens

Trigger: Editing src/main/assembly/conf/sonar.properties and adding a non-comment, non-empty line (e.g. uncommenting sonar.jdbc.username=... or sonar.web.port=...), then running a build that depends on verifySonarProperties.

Common situations: Developers editing the shipped default file to test configuration instead of their local instance's conf; accidentally uncommenting a line while reading the template; automated scripts rewriting the file.

Understand the failure class

Background: "Invalid value" and "allowed values are" config errors: what your library rejected and how to fix it — this error's family across 41 libraries.

Related errors

AI-assisted analysis of SonarSource/sonarqube@184c821202 (2026-09-09). Data as JSON: /api/errors/952b5edb29295c87. Report an issue: GitHub.