Pass In Secure sonar.login token with -Psonar.login and SonarProperties.java?

Tech Stack context: Gradle / Kotlin / Jenkins

I would like to be able to obfuscate the sonar.login token with the Jenkins Credentials Binding plugin.

This works fine if I call something like:

withCredentials([string(credentialsId: 'SonarToken', variable: 'SONAR_TOKEN')]) {
  sh './gradlew sonar -Dsonar.login ' + "${SONAR_TOKEN}"
}

Unfortunately, for various reasons I’m not able to use -D arguments for these commands.

Gradle properties (i.e. -P) are available, but -Psonar.login doesn’t seem to work, e.g.:

withCredentials([string(credentialsId: 'SonarToken', variable: 'SONAR_TOKEN')]) {
  sh './gradlew sonar -Psonar.login ' + "${SONAR_TOKEN}"
}

Even when the build.gradle.kts tries to set the sonar.login to it:

sonarqube {
    properties {
        property("sonar.login", "${properties["sonar.login"]}")
    }
}

Where properties refers to SonarProperties.java.

Am I misunderstanding how to use SonarProperties.java properly?

Hey there.

Can you outline what those reasons are?

Restricting -D params allows a DevOps / Arch team to have more predictable control over the java environment. Theoretically this could be raised as an exception, but ideally we wouldn’t need a special exception.

I’m having some luck setting the build.gradle sonar.login param to a gradle var (similar to the OP), but I’m still working on getting a clean result from that. So I’m still interested in other potential options.

What about using the SONAR_TOKEN environment variable in your build?

It’s possible there could have been a way to get that to work, but I tried a few different versions and every time the Jenkins Credentials Binding plugin obfuscated the env var in the places that I needed to access it.

FWIW, I got it working by a somewhat unconventional approach, by adding the login token to the sonar-projects.properties file, and then reading in values from the properties file into the sonarqube gradle plugin in build.gradle.kts. With this setup the properties file doesn’t actually do anything, other than storing values which can be read into the build.gradle.kts file, but it’s working for letting me obfuscate the token end-to-end.

Something worth considering, in the interest of giving users more options to work around edge cases, would be to allow the sonarqube gradle plugin to automatically work with a sonar-project.properties file. That way users have more options for defining params and getting them picked up correctly.