SonarQube version: 8.2.0.32929 running on Windows 2012 R2 using https and SSO to Azure AD
SonarQube Extension for Azure Devops version 4.9.0 (latest)
When the Run Code Analysis step is run in our build pipeline, we are getting the following error:
2020-04-15T11:40:02.2660555Z INFO: Analysis report generated in 15026ms, dir size=93 MB
2020-04-15T11:43:06.2158310Z INFO: Analysis report compressed in 183953ms, zip size=30 MB
2020-04-15T11:43:20.4228790Z INFO: ------------------------------------------------------------------------
2020-04-15T11:43:20.4230517Z INFO: EXECUTION FAILURE
2020-04-15T11:43:20.4234912Z INFO: ------------------------------------------------------------------------
2020-04-15T11:43:20.4235847Z INFO: Total time: 10:23.057s
2020-04-15T11:43:20.5354232Z INFO: Final Memory: 21M/420M
2020-04-15T11:43:20.5356028Z INFO: ------------------------------------------------------------------------
2020-04-15T11:43:20.5371987Z ##[error]ERROR: Error during SonarQube Scanner execution
2020-04-15T11:43:20.5372724Z ERROR: Error during SonarQube Scanner execution
2020-04-15T11:43:20.5373419Z ##[error]ERROR: Failed to upload report - HTTP code 413: The page was not displayed because the request entity is too large.
ERROR:
2020-04-15T11:43:20.5374401Z ERROR: Failed to upload report - HTTP code 413: The page was not displayed because the request entity is too large.
2020-04-15T11:43:20.5374687Z ERROR:
2020-04-15T11:43:20.6452268Z ##[error]The SonarQube Scanner did not complete successfully
2020-04-15T11:43:20.6455414Z The SonarQube Scanner did not complete successfully
2020-04-15T11:43:20.6509922Z ##[error]07:43:20.642 Post-processing failed. Exit code: 1
2020-04-15T11:43:20.6511557Z 07:43:20.642 Post-processing failed. Exit code: 1
2020-04-15T11:43:20.8144627Z ##[error]The process āD:\Agents\b1_work_tasks\SonarQubePrepare_15b84ca1-b62f-4a2a-a403-89b77a063157\4.9.0\classic-sonar-scanner-msbuild\SonarScanner.MSBuild.exeā failed with exit code 1
2020-04-15T11:43:20.8227952Z ##[section]Finishing: Run Code Analysis
We changed the IIS setting uploadReadAheadSize to its maximum allowed value.
we have enable āNegotiate Client Certificateā for the certificate bindings
we have set maxAllowedContentLength to its maximum value 4294967295
This issue is usually related to the configuration on a reverse proxy, as opposed to the SonarQube server. Are you using a reverse proxy setup by chance?
Yes, as I understand it, itās the only way we can us https with SonarQube. As noted I have already made 3 changes that were suppose to address the proxy.
Interesting. Can we double-check whatās set for sonar.host.url to make sure weāre sending the analysis to the intended site? Those configuration changes usually solve the issue.
I should point out that this in not failing on all scans. The general configuration is correct, since the build in question is successfully uploading scans of other components. Its just one
component with a 30MB Analysis report thatās failing.
INFO: Analysis report generated in 17022ms, dir size=93 MB
INFO: Analysis report compressed in 195757ms, zip
size=30 MB
If the 413 error is still present, the only cause I can think of is a failure for the configuration changes to take effect in IIS. I would recommend checking the IIS logs around the time of failure, and even around the time of changing to configuration to ensure the changes have been applied.
The changes were applied some time ago now, so I donāt think I would be able to locate the logs for when the configuration was changed. I did take a look at the logs and compared a successful
upload to a failed one. The failed one is below. I donāt know what to make of it as I have very little experience reading IIS logs. Any incites would be appreciated
2020-04-22 10:32:05 172.16.3.8 GET /batch/project.protobuf key=BM*******tion&X-ARR-CACHE-HIT=0&X-ARR-LOG-ID=aaa0c150-69b5-40af-854c-065464be488b&SERVER-STATUS=404 443 - 40.121.111.108 ScannerCli/4.2.0.1873
Thanks for that info. Iām also a bit fuzzy on IIS logging, but I found a nifty guide that does a pretty good job of outlining. It looks like a sticking point for our 413 errors is that thereās not much info on where that error is coming from, but we can dig a little deeper. If you set āsonar.web.accessLogs.enableā to ātrueā in your āsonar.propertiesā file, SonarQube will write similar logging to āaccess.logā. A good next step would be to replicate the issue with the access log enabled, and then compare the IIS entry timestamp with the entries in āaccess.logā around that time. Another option would be to bypass the reverse proxy and send the analysis at the SonarQube server. I recommend the latter as a sanity test.
Thatās great to hear! maxRequestEntityAllowed seems like the one that would directly affect this, and I think that extra zero is most likely what fixed the issue. All that being said, Iām definitely not an IIS expert, but itās good to know we can read up on the other settings at our leisure.
This is nothing specific to SonarQube, you could have the same problem with any web app that posts big enough payloads through IIS. You should ask this to Microsoft or search elsewhere on the internet