This also made creating and maintaining new builds from a shared template much simpler. We used to have almost all the tasks as individual build steps in TeamCity but found that it was adding unnecessary time to our build pipeline and intentionally condensed them back down. We run our builds through TeamCity, and if we were to separate the build from analysis into separate build steps, there are some gradle tasks that would be executed more than once unnecessarily (things like retrieving the version from TeamCity parameters so it’s available to the gradle process, etc). Does the server send custom files back to the scanner to use?

Is it possible, using a SQ plugin config param, CLI argument, environment variable, or otherwise, to tell the sonar scanner to use a different JDK/JRE than the one the gradle process that calls the sonarqube task was invoked from?Īs an aside, I find it interesting that this behavior appears when I change only the property and the sonar.login property everything else is the same between my SQ 7.6 execution and my SQ 9.5 execution. I tried simply updating the version of the SQ plugin we’re using to the latest, but that didn’t resolve the issue.

The entire set of Gradle tasks (including the sonarqube task) is executed from a single entry point task, so the entire thing runs as a single Gradle process.ĭuring our experiments we are running into the famous issue:Ĭaused by: : org/sonar/batch/bootstrapper/EnvironmentInformation has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0 obviously because the entire process is running against the Java 8 JDK/JRE.īecause we invoke the sonarqube task as part of the entire build chain, the solution discussed in Moving Analysis to Java 11 | SonarQube Docs will not work for us, as we don’t invoke gradle separately for build vs analysis.

Our builds are Java builds targeting Java 8 using Gradle to orchestrate, running against a Java 8 JDK/JRE as specified in JAVA_HOME on our TeamCity build agents. We are attempting to transition from our existing SQ setup (7.6) to a new one (9.5).

Download teamcity sonarqube