I’ve also attempted to run sonar-scanner manually.
The last few lines before the process appears to hang are:
16:49:02.940 INFO: Project root configuration file: NONE
16:49:02.952 INFO: SonarScanner 126.96.36.19947
16:49:02.952 INFO: Java 11.0.17 Homebrew (64-bit)
16:49:02.952 INFO: Mac OS X 12.6.1 aarch64
16:56:04.141 DEBUG: eslint-bridge server closed
16:56:04.141 INFO: Time spent writing ucfgs 5112ms
16:56:04.149 ERROR: isAlive was interrupted
Thanks for reporting this.
From what we could see on our side, it seems the failure of the Automatic Analysis comes from the JS security analysis. The error you reported from the local scan seems unrelated: did you reproduce the analysis in the same conditions (same amount of memory, same nodejs version) ?
Regarding the problem of the JS security analysis, it is hard to pinpoint exactly the source of the problem without a reproducer. Would you be willing to share the yourProject/.scannerwork/ucfg2 folder of a local scan with us privately? That’s the basis used for the security analysis, and would greatly help us to investigate and understand the root of the issue.
In the meantime, you can disable the rules related to the JS Security analyzer as a temporary workaround (these are the rules: S2076, S2083, S2631, S3649, S5131, S5144, S5146, S5147, S5334, S5696, S5883, S6096, S6105, S6287, S6350). This is definitely not ideal, but would at least let you run the analysis for all the other rules.
Thanks again for sharing the UCFGs with us, it was very helpful!
I was able to identify a bottleneck regarding memory consumption during the analysis.
A fix is underway and should be put in place in the coming days.
Thanks for your patience so far.
No update on the scanner side is needed, when a new analyzer version is released, it is downloaded by the scanner from SonarCloud, so the analysis benefits from the fixes right away.
In the meantime, we’ve continued investigating some performance issues in the security analysis, and we’ve identified a bottleneck. We’re in the process of releasing it, and the new version should be deployed on SonarCloud in the next few days.
However, when looking at the logs of the analysis you’ve provided (Analysis ID “ee080fd1-e0d0-413c-8ff2-046d7daf4d41”), it seems the timeout occurred at the SCM Publisher step (after the analysis).
The new improvements done to the security analysis could be enough to make the automatic scan succeed directly, however, if the issue with the SCM Publish step persists after the fix is deployed, it might mean that using automatic analysis is not suitable for the project anymore and might require a CI-based analysis instead.