Recently we have migrated sobarqube from one cluster to other and with that we have also upgrade to latest version from 9.3. Initially, analysis was running slow, which we solved by increasing container memory. but after few days, we are experiencing SonarQube: Publish Quality Gate Result task is running very slow. It usually is about few seconds to max of 30 but last few runs we have seen to 15 minutes and one with about 58 minutes which failed due to time-out.
We are using this task in template : SonarQubePublish@5 - Publish Quality Gate Result v5 task | Microsoft Learn
- which versions are you using : 10.3.0 - enterprise
- how is SonarQube deployed: Helm
How this can be troubleshooted? or what is remediation steps?
I am not sure if this makes any difference, but we had experinced this similar issue also : Sonarqube helm deployment is crashing on running the init-sysctl container
and applied temporary fix of modifying extrainitcontainer configs.
EDIT : what we are seeing is sonarqube is not able to publish back to azure devops only if quality gates results are failed. Successful ones are being published fine within few seconds except some took 10-15 minutes but it is not constant.
Is there anything interesting in your server logs (probably
No, nothing in any log file. Also, background tasks in SQ doesn’t have anything. Issue more seems to be in integration to azure devops rather than sonarqube itself.
Since there’s nothing in your logs (that was kinda a long shot) I go back to your original post… and find it very odd that the behavior varies by Quality Gate status. I’m wondering if there’s not something “helpful” on your network that’s interfering with the communication. Can you check with your network folks?
Did some more due diligence and it’s now not just with failing quality gates. slow run has happened with passed quality gates. We have added new waiting period between analysis and publish task to give some time to sonarqube to prepare for publishing.
Speaking of networking, nothing to do with that as this is fully azure hosted and it was just like that since beginning. It is not just slow run, but something in sonarqube is not able to send quality gates results to azure devops.
Is there a way to check process of publish tasks in sonarqube server? Background Tasks under management doesn’t list them.
Sending results outside of SonarQube comes at the very end of analysis report processing. So, can you verify that you see updated analysis results in SonarQube (i.e. report processing is complete) and then there’s this long wait for posting to ADO? Or is there a long wait after analysis is complete on the build agent, and then SonarQube and ADO are updated around the same time?
we have 3 pipeline tasks in build stage: Prepare, Analyze and Publish. Prepare and Analyze works perfectly well. Analyze task send code to SQ for analyzing and it runs for sometime and once that is completed, publish tasks starts.
Now, coming to your question, publishing results to sonarqube(probably DB) and publish command at pipeline are being done at almost same time. As this both processes are done in milli-seconds, we can’t tell which happened first.
What our guess is, that if pipeline try to publish results before they are ready in sonarqube, It goes nowhere. and then pipeline publish tasks runs indefinitely. May be it is not designed to re-try or not able to get data from sonarqube.
From official Sonarqube doc:
Publish quality gate result : This task displays the quality gate status in the build summary letting you know if your code meets quality standards for production. This task may increase your build time as your pipeline has to wait for SonarQube to process the analysis report.
Is there a way we see how long it took for sonarqube to process the analysis report? This might not be same a actual analysis runtime.
Okay, so the job hangs after analysis is fully complete, SonarQube is updated and PRs (if relevant) are decorated. Then this probably is about the timing of the Quality Gate check. For a job where this took a long time or timed out, can you check the corresponding project’s background tasks, pinpoint the relevant row and see what the timings were?
I believe some people do add a quick pause after analysis and before checking the Quality Gate result (although, really you shouldn’t have to).
Background tasks only shows analyze tasks. which are under 1 minutes and similar to time in sonarqube analyze task in pipeline. any other way of looking at publish task logs?
We have just added pause before publish task, which seems to have working good so far. But As you said, we dont have to and we didn’t have this before with older version.
Also, I saw many of other people have experienced similar: Publish Quality Gate Result taking time of about 1hr and task automatically get cancelled - #3 by Tusharghule
No, the background tasks page won’t show the publish step because it doesn’t happen on the SonarQube side. Processing the analysis report “publishes” the result to SonarQube. The “publish” task simply retrieves the status from the server. What I was looking for was whether the analysis report processing finished very quickly after the initial submission or whether there was a lag there.
No, there wasn’t any lag in analysis.
We have had instances where analyze task took longer than normal time, but then in same pipeline run, publish task finished in 2-5 seconds.
@ganncamp Wait task didn’t help us either. I had same issue yesterday with waiting for 30 seconds.
What I’m asking is whether there was a lag between the end of the CI-side analysis (i.e. the submission of the analysis report) and the end of its processing on the SonarQube server side.
I would say Yes. What I saw in morning was, in devops pipeline analysis was completed but in sonarqube it was saying “preparing for analysis” and not showing that analysis in project. So most probably it was in pending in background tasks.
I dont understand how come analysis is completed in devops pipeline but pending in sonarqube?
When CI-side analysis is complete, an analysis report is bundled and sent to the server. There, it’s queued for processing and your project is updated once the report is popped off the queue and processed server-side.
Depending on the load on your server and the sizes of your other projects, this can be very quick or it can take a while.
So the thing to look at now is the difference between when the relevant reports are Submitted versus when they’re finished. Go to Background Tasks to see this:
Note that this is a project-level list, but a global list of all background tasks is available under Administration.
thanks Ann. That’s what it could be the issue. Any stable solution for this? We have increased number of workers but this can still fail whenever there is large code change published.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.