Deploying SonarQube through Helm Chart - automating global reportPaths

SonarQube Community Edition - Version 9.6 (build 59041)

We are trying to deploy SonarQube through the Helm Chart, and we want to automate as much of the configuration as we can.

sonarProperties seemed like a good lead, and we managed to defined sonar.core.serverBaseURL, and the sonar.auth.gitlab.* settings through it. However, when trying to define *.reportPaths through it, the config seemed to be ignored :

    sonar.dependencyCheck.htmlReportPath: "var/ci/reports/owasp-dependency-check/dependency-check-report.html"
    sonar.dependencyCheck.jsonReportPath: "var/ci/reports/owasp-dependency-check/dependency-check-report.json"
    sonar.javascript.lcov.reportPaths:    "var/ci/reports/js/"
    sonar.php.coverage.reportPaths:       "var/ci/reports/php/coverage.xml"
    sonar.php.phpstan.reportPaths:        "var/ci/reports/php/phpstan.json"

Am I missing something? Is this intended behaviour?


It’s basically a bug that you’re able to define sonar.core.serverBaseURL via the properties file. The things that are defined (and define-able) in the properties file do not appear in the UI and vice versa.

So what you’re experiencing is intended behavior.

And, perhaps it will set your mind at ease to know that what’s defined via the UI is stored in the DB, so there’s no need to re-define it at each startup. And the few UI properties that you’re defining in the config file are not being stored in the DB, so you probably want to normalize your handling of them.


Alright, that makes sense :frowning:

Do you have any recommendation to automate this kind of configuration? (through the API maybe?). Or is the solution to just configure it through the UI and take good care of the database and back-it up?


I would hope that taking good care of the database and backing it up would just be your default. :smiley:

And yes, you should be able to do the initial config via the API if you just really don’t want to use the UI.


1 Like