- ALM used Azure DevOps
- CI system used Azure DevOps
- Scanner command used Standalone Scanner
We’ve been experiencing some problems when trying to scan some of our TSQL code using the standalone scanner. We are getting what we perceive as timeout issues. The top of the logged error looks as follows;
2019-10-30T12:46:16.0049526Z ##[error]12:46:15.989 ERROR: Error during SonarQube Scanner execution
2019-10-30T12:46:16.0051612Z 12:46:15.989 ERROR: Error during SonarQube Scanner execution
2019-10-30T12:46:16.0052784Z ##[error]java.lang.IllegalStateException: Fail to request https://sonarcloud.io/api/ce/submit?organization=ipsl-sonarcloudkey-devops-lspi&projectKey=iPSLAz_DEW_Database&projectName=DEW_Database&characteristic=pullRequest%3D274
2019-10-30T12:46:16.0053914Z java.lang.IllegalStateException: Fail to request https://sonarcloud.io/api/ce/submit?organization=ipsl-sonarcloudkey-devops-lspi&projectKey=iPSLAz_DEW_Database&projectName=DEW_Database&characteristic=pullRequest%3D274
Further down the log there is a ‘java.net.SocketException: Connection reset by peer: socket write error’ which points to it being a connection issue.
Within the ‘Prepare analysis on SonarCloud’ Azure DevOps module we have set the following additional properties;
sonar.verbose=true
sonar.ws.timeout=600
We can see that sonar.verbose = true in the log produced by the prepare analysis step but there is no logging to indicate that we have overridden the timeout. For a short while after adding these extended properties we also continued to experience what appeared to be connection issues.
- Should the sonar.ws.timeout be logged anywhere when using the devOps components?
- Is the original timeout cached, which means we need to wait for the cache to reset before the new timeout comes into play?