Understanding the Motivation to use withSonarQubeEnv in Jenkins Pipeline

I am using SonarQube 9.8 Developer Edition.

I am trying to Optimize the duration (Currently 10-15 mins) of the Sonar Analysis Stage in my Pull Request builder (Implemented using JenkinsFile).

I have a multi-stage PRB (for a Monolith) with Sonar Analysis Stage. The PRB is implemented using Jenkins Pipeline. In the Sonar analysis Stage I am simply picking up a Jenkins Node and trigger the analysis which in total takes 10-15 mins. I am not using the Jenkins Sonarqube extension (Jenkins extension for SonarQube). I have added Sonar Scanner maven dependency to my Project during the Sonar Analysis Stage. I simply invoke the mvn sonar: sonar with the sonar.host.url and other parameters.

I am trying to understand if using the Sonarqube Jenkins extension gives me any advantage over directly invoking sonar analysis via mvn (assuming sonar scanner is in project dependencies). Could you please provide me with some insights?

I’m not sure if we’re talking about the same things, but we use the “withSonarQubeEnv” and “waitForQualityGate” pipeline steps. Within the “withSonarQubeEnv” block, we run “mvn sonar:sonar” (we set all the required properties on the command line, instead of in a properties file). The purpose of “withSonarQubeEnv” is to set appropriate environment variables (username, password, and url) corresponding to the specified SonarQube instance (we have a production instance and a test instance that we use for testing SonarQube upgrades). The “waitForQualityGate” step checks on the status of the background tasks, so we can determine whether the quality gates on the scan passed.

Addressing your question, you don’t choose the pipeline steps instead of “directly invoking sonar analysis”, you use them both at the same time.

And note that you generally don’t need to specify any dependencies in the project pom.xml, just running “mvn sonar:sonar” will get the latest version. If we actually needed to specify an older version, we can fully qualify the version on the command line.