Version 7.9.1 (build 27448)
I use Quality Gate API to get the status of sonar run
stage(‘Sonar’) {
steps {
script {
setSonarProjectInformation()
}
doSonar() (<— runs sonar:sonar goal —>))
script {
sleep(time:30,unit:“SECONDS”)
def qualitygate = getQualityGateStatus() ← uses API quality /api/qualitygates/project_status?projectKey=projectcoordinate—>
def email_body = getQualityGateMailBody() <-calls quality API again to form email body–>
if (!qualitygate){
sendEmail(null,‘Sonar Quality Gate Failed…!!’,email_body)
}
}
}
}
Problem is that first API call after sonar scan gives Quality Gate Status as false where as second call made to same qualitygate api to get and prepare email body retuen qulity gate passed why? and since first call was giving false positive emails are triggered.
Question is why first api call return wrong QG status where as second API call return right QG status?
Note that there’s no explicit call to the sever in our recommended pipeline.
In your example, you start by retrieving the current QG status for the project. At a guess, even with a wait of 30 seconds, your analysis report hasn’t yet been processed when the call is fired, so what you’re pulling back is the status of the QG before the analysis. If you really want to do this manually, then you’ll need to dig into the files in the .sonar directory to retrieve the analysis_id and get its status. BTW, that’s a different web service.
Adding to what Ann said, what you’re waiting for here is the “background task”, which executes after the scan completes. It can take between 10 seconds and a couple of minutes to execute, depending on the load on your SonarQube server. If it takes 2 minutes to run and you check the status only after 30 seconds, then you’ll get an incomplete status.
Since you’re clearly using Jenkins, you really should be using the “withSonarQubeEnv()” and “waitForQualityGate()” pipeline steps. The former takes a SonarQube instance name and sets the authentication and url properties based on that. The latter checks the quality gate status (in a wait loop), but it also waits for the “webhook” call from SonarQube to Jenkins, indicating that the background task is complete.