which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)
sonarqube: Version 8.1 (build 31237)
sonarqube jenkins plugin: v2.11
what are you trying to achieve:
I am currently using following:
I do this for QG check in pipeline but its not 100% reliable and occasionally it stucks and times out. So I am thinking to do a custom check (polling api endpoint) and remove waitForQualityGate however for that I would need sonarqube server information and ce task id after the analysis has been triggered. Can I get this information from an environment variable?
If all is configured properly it works 100% reliable.
Seems the Jenkins > Sonarqube (uploading the report archive …) part works,
so you need to check the Sonarqube > Jenkins part.
There are several posts in this forum dealing with this, see https://community.sonarsource.com/search?q=Jenkins
The details you’re looking for are in Jenkins/workspace/yourjob/.sonar/report-task.txt.
It has projectKey, serverUrl, serverVersion, dashboardUrl, ceTaskId, ceTaskUrl.
Hi Gilbert, my configuration is correct otherwise it wouldn’t work at all.
I know that its not 100% reliable however it might not be related to sonarqube… could be some network inconsistency etc. don’t know… Also not sure whether a retry is implemented in case of webhook delivery failure etc.
Anyways, I am going to use report-task.txt to get information and implement pull approach, rather than webhook-push approach for now.
Your implementation based on web-hooks is correct and switching to a polling model would make things less nice (and you’d still get the same problem).
The general problem is: You can’t hold a Jenkins job for ever, in case the quality gate cannot be computed, the web hook cannot be fired, or whatever network issue, there can be a small % of the time where the information will not come, or come too late (regardless if you’re using web hook or polling)
The key question: How much time maximum should you wait (for the web hook, or loop on polling) before you decide to give up, and it cannot be infinite.
In your pipeline you chose a timeout of 10 minutes (timeout(time: 10, unit: 'MINUTES')). If you want to increase your success rate (and can afford to hold the jobs that long) you can increase this to 30 minutes for instance. But not setting will allow a 100% success rate (again whether it’s web hook based or polling based)
You should look also at the performance tuning of your SonarQube platform. The web hooks are fired when the backgrounds tasks are finished processing, and the processing time depends on your SonarQube platform performance.
Again, please, don’t use polling, you’ll not fix you problem and you’ll have a less elegant integration
Sonarqube itself was always working fine and analysis was completed quickly within a minute.
There was something else going on w.r.t. sonarqube->jenkins communication and it was timing out once in may be 30-40 times.
I added poll approach and so far not a single issue. It gives me full control over failure handling/retries etc. Will keep it for now and see how it goes.
Hello Kumar,
Fair enough. From what you describe the problem seems to be in the infrastructure to be between your SonarQube and Jenkins. If polling works better for you, so be it, but you realize I guess that it’s consuming more resources in Jenkins than with web hooks.
Topic closed I guess.
Regards
we experienced this problems with the Sonarqube webhook > Jenkins part:
a)
wrong webhook configuration
b)
missing nonProxyHost settings
c)
use SonarScanner in parallel with Jenkinsfile to speed up npm builds with lot of modules
there are some glitches in that area, see this related Jira ticket https://jira.sonarsource.com/browse/SONARJNKNS-300
We can exclude a) and b) in your case, as that would never work and you reported intermittent problems. That’s exactly what we’ve noted with c). Do you use parallel Sonar scans in your pipelines ?
Adding a sleep of 10 sec between Sonarqube analysis and quality gate stage might help also.
This increases the chance that the background task has already finished, so no more waiting for
the webhook. This is still simpler than the polling approach.
You may either go with adding a sleep or polling in your pipeline or
check your webhooks = /admin/webhooks , configuration and deliveries
in our case = c) all deliveries were successful
create a Jenkins logger for Sonarqube plugin
you’ll see the JSON payload if delivered successfully, see analysid
if this is the case and you get a timeout nevertheless, it’s a problem of
Sonarqube Jenkins plugin not consuming the payload
this also means you can exclude network problems, as JSON payload has been transmitted
Thanks Gilbert for detailed information.
We don’t use sonarscanner in parallel in same build. Its possible that build-A and build-B of different projects (may be same project sometimes) might be scanning at same time.
For now, our poll mechanism is working great for our frequent build projects. I still have webhook approach in some not-so-frequent builds. Can check more once I see it next time.
however it might not be related to sonarqube… could be some network inconsistency etc. don’t know… Also not sure whether a retry is implemented in case of webhook delivery failure etc.