SonarQube version: 220.127.116.11929 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.
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.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.
The value is set correctly
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
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 - 18.104.22.168 ScannerCli/22.214.171.1243
2020-04-22 10:33:15 172.16.3.8 GET /api/metrics/search f=name,description,direction,qualitative,custom&ps=500&p=1&X-ARR-CACHE-HIT=0&X-ARR-LOG-ID=ac8d2ed0-0fb8-4119-83b3-ef3d591a3e0a&SERVER-STATUS=200
443 - 126.96.36.199 ScannerCli/188.8.131.523 - 200 0 0 15
2020-04-22 10:35:52 172.16.3.8 POST /api/ce/submit projectKey=BMUI&projectName=BMUI&characteristic=branch%3Dfeature%2Fsupernovae%2Fmain&characteristic=branchType%3DBRANCH&X-ARR-CACHE-HIT=0&X-ARR-LOG-ID=28fb41bd-3ba8-4677-b316-6774de0013f1&SERVER-STATUS=200
443 - 184.108.40.206 ScannerCli/220.127.116.113 - 200 0 0 2626
2020-04-22 10:41:45 172.16.3.8 POST /api/ce/submit projectKey=BM***********tion&projectName=BM*************tion&characteristic=branch%3Dfeature%2Fsupernovae%2Fmain&characteristic=branchType%3DBRANCH
443 - 18.104.22.168 ScannerCli/22.214.171.1243 - 413 1 0 0
#Software: Microsoft Internet Information Services 8.5
#Date: 2020-04-22 11:21:27
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken
2020-04-22 11:21:27 172.16.3.8 HEAD / X-ARR-CACHE-HIT=0&X-ARR-LOG-ID=3616bb5b-359d-4e1b-9c14-43d0297db69b&SERVER-STATUS=200 443 - 126.96.36.199 Mozilla/5.0+(Windows+NT+6.1;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/40.0.2214.85+Safari/537.36
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.
Actually I think I fixed it.
I changed maxRequestEntityAllowed from 30000000 to 300000000 (approximately 28mb to 286mb, the file size that was failing was 30mb).
To summarize, I previously change the following.
The IIS setting uploadReadAheadSize to its maximum allowed value.
Enable “Negotiate Client Certificate” for the certificate bindings
Set maxAllowedContentLength to its maximum value 4294967295
I’m not sure the previous changes helped or not, but it’s working now so I’m leaving them as is.
Thanks for the help!
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.
I am also facing this issue.
What IIS setting and what exactly I need to do?
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