We currently use sonarcloud in our CI/CD pipeline to perform an analysis on new code and pull requests. Lately we have seen some degradation in the performance of sonarcloud.
In our Jenkins pipeline a sonarscanner command is fired which should trigger an analysis on sonarcloud. Up until last week it went fine, but we noticed that the Jenkins step is waiting on response from sonarcloud to mark the analysis as complete. When we look in the background tasks, we actually see that the analysis is triggered, but has the pending status. Sometimes it will hang at this point and our Jenkins build will fail because of the timeout. There is no way to trigger the analysis from pending to started, even with the restart trigger. This behaviour also sometimes happens with pull requests, where a completed sonar analysis is a mandatory check. When this happens we are not able to merge, because we don’t get any response back from sonarcloud.
Our current workaround is to completely disable the sonar analysis altogether, but this is not something which is a working solution for us in the long run. We would like to know why the performance of sonarcloud went down the last few weeks.
Are you suggesting that the analysis seems to take longer than before? If so, are you sure you are comparing similar subjects? That is, same project, with no significant change in code size? (With all things being the same, I’m not aware of a reason at our side for slowness to suddenly appear.)
If analyses really seem slower, do you see that consistently (all analyses are slow), or only sometimes? Would you be able to do a simple experiment: take a commit that was analyzed quickly before, analyze it again and see if it’s significantly different from before (over a few such runs).
Just out of curiosity, can you please share:
ALM used (GitHub, Bitbucket Cloud, Azure DevOps)
Scanner command used when applicable (private details masked)
Languages of the repository
Only if the SonarCloud project is public, the URL
What is this “restart trigger” you’re referring to?
Do you mean that you are observing the performance degradation mostly when analyzing the main branch, and less often when analyzing pull requests?
It is not that the analysis seem to take longer than before. The problem we are facing is that sometimes the background task in our Sonarcloud environment gets stuck on the “pending” status. So we can’t really reproduce the problem.
For some more context: A sonar-scanner command is fired from our Jenkins build (connecting to our Sonarcloud environment), which in 9/10 times works perfectly fine, but in the last two weeks we noticed that sometimes a task never changes from the pending status. As a result, the analysis is never performed and our Jenkins build fails on a timeout.
The restart trigger I am referring to is specifically for PR analysis. We have Sonar as a check on GitHub, which needs to succeed in order to merge a PR. This behaviour occasionally happens with these analysis as well. On GitHub it is possible to “retrigger” the check, but that actually doesn’t do anything.
The occurrence of this problem really is random. We don’t notice it more or less with certain analysis.
Below are some configs we use:
Jenkins pipeline, with a Sonar-scanner step (triggered by GitHub push)
We are seeing peaks in activity on the background tasks queue on every working day in the middle of the afternoon (European time). Analyses that arrive during a spike may have the effect you are observing. Do you see a correlation in the time when you tend to get timeout errors?
Indeed, the Restart link on GitHub Checks does nothing (it just cannot, when the scanner is launched from an external system, not GitHub).
The tasks that would get stuck on “pending” were performed during the day (between 2 pm and 3 pm GMT+2). Other than that there are no correlations or expected behaviour, and the issue seems to pop up at random.
Are there any options to retrigger a pending job? We know would have to restart the whole build, or disable Sonar altogether. Either options are not preferred.