Hi,
I’m using sonarqube developer 7.6 version. After sonarqube analysis, for quality gate stage I set time out 15 mins in Jenkins.
Now, the background analysis took 6 mins in sonarqube server but in Jenkins build failed beacause of time out. Quality gate stage is waited for 15 mins to get response from sonarqube server.
So, is it because of two parallel background tasks in sonarqube or Do I need to add any parameter ?
Can please some one help me on this issue.
Sorry about that. Does sonarqube developer 7.6 support parallel background analysis in same project. Ci builds are failing because of background analysis didn’t send response to Jenkins.
You’re saying that when there’s no 2nd background task being processed the webhooks work, and when there is they don’t work? Can you provide logs or error messages?
Error message is something like Quality gate is timeout. The logs you asking weblook deliveries or ?
Can you please confirm weather sonarqube do parallel background analysis and is the webhook can deliver parallel analysis status??
From webhook and Jenkins there are no errors It receives 200 response.
I Configured webhook in sonarqube for project as http://jenkins:8080/sonarqube-webhook/
Is this the way correct or Do I need to add any parameters?
Yes, I used withSonarQubeEnv method. It is working with one analysis but it is happening when other analysis is in queue in same project.
Is webhook configuration correct or do I need to add any other info in Sonarqube and Jenkins?
I configured in sonarqube server webhook as “http://jenkins:8080/sonarqube-webhook/”
Yes @ganncamp
when there is queue don’t work. I’m using sonarqube developer edition. I’m not able to share logs. And again there are no error messages. Webhook has 200 response and jenkins has no errors.
I think here there is a problem with taskId. When an analysis is submitted to SonarQube, a unique taskId is generated. waitForQualityGate will then wait for a webhook with the same taskId to resume.
It is a bit difficult for us to investigate without having a full pipeline declaration. For example I don’t really understand what you call two parallel background tasks? You can submit to SonarQube a new analysis even if the previous one is not completed. Each analysis will be queued to be processed, possibly in parallel depending on your edition, and depending if this is an analysis for the same project.
On Jenkins side, the key is that we are storing the taskId in a build action (let say this is the build context). This is done by the withSonarQubeEnv. Then waitForQualityGate will wait for the latest task to complete.
So this use case is supported:
withSonarQubeEnv() {
// run analysis 1
}
waitForQualityGate() // will wait for task 1 to complete
withSonarQubeEnv() {
// run analysis 2
}
waitForQualityGate() // will wait for task 2 to complete
But this will not work:
withSonarQubeEnv() {
// run analysis 1
}
withSonarQubeEnv() {
// run analysis 2
}
waitForQualityGate() // will wait for task 2 to complete
waitForQualityGate() // will wait for task 2 to complete, and wait forever since the webhook have been already 'consumed'
In my project we have multiple branches. In CI jenkinsfile we have stages one sonarqube after quality gate stage with methods
withSonarQubeEnv() {
// run analysis 1
}
waitForQualityGate() // will wait for task 1 to complete
Here what happened with in the project project multiple branch analysis triggered in Jenkins. Now in sonarqube second background analysis is queued untill the first analysis completed. But in this case webhook is not returning status of first analysis.
OK, so you have separate builds for different branches of the same project.
Can you investigate if the two webhooks are correctly sent from SonarQube to Jenkins? I would like to know if the issue is on SonarQube server side or on the Jenkins plugin side.
Please look at webhook deliveries UI in SonarQube. You can also look at Jenkins log, where there should be an INFO log like:
You can also configure log level of the org.sonarsource.scanner.jenkins.pipeline.SonarQubeWebHook logger to FINE to see the content of the payload (this could help to see if the taskId is correct).