Unable to analyze typescript project

SonarQube Server / Community Build
,
1

We have an outdated SonarQube Enterprise 8.1 server that is not able to analyze our newer Typescript projects given to it being out of date.

While we wait for the IT org to get the platform upgraded, we downloaded both the docker container image and windows ZIP files for versions 8.9, 9.9 and 10.3, using sonar scanner via docker image or ZIP download for versions 5.0.1 and 4.81 and are unable to get the scan to complete. The git project has 4 submodules and approximately 1500 files to be analyzed.

Other than it taking a very long time, it hangs attempting to start up the node server and we get a bundle server timeout error on every combination of the above.

I looked through a bunch of posts and see similar issues being reported. I have increased the memory. We are running the sonar scanner on a windows 10 enterprise VM with 4 cpu and 16 GB of RAM. I saw the post to increase the memory which also doesn’t work.

sonar-project.properties:

sonar.projectKey=XXXXX
sonar.projectName=XXXXX
sonar.verbose=true
sonar.exclusions=node_modules/**, **/coverage/**, ./src/**/*.stories.js, ./src/**/*.test.js, ./src/test-utils/**,.next/**,.cache/**,yarn.lock
sonar.test.inclusion=**/*.test.js
sonar.test.exclusions= ./src/**/*.js, ./src/**/*.json, **/__mocks__/**, ./src/**/*.test.js, ./src/test-utils/**
sonar.coverage.exclusions=**/*.stories.js, **/*.test.js, ./src/test-utils/**, ./src/setupTests.js
sonar.javascript.lcov.reportPaths=/usr/src/app/coverage/lcov.info
sonar.javascript.node.maxspace=6144

It takes a long time for things to start:

16:51:57.903 DEBUG: Using Node.js v18.17.0.
16:51:57.904 DEBUG: Starting Node.js process to start eslint-bridge server at port 33205
16:51:57.904 DEBUG: Launching command node --max-old-space-size=6144 /usr/src/.scannerwork/.sonartmp/eslint-bridge-bundle/package/bin/server 33205 127.0.0.1 /usr/src/.scannerwork true false
16:54:55.812 DEBUG: starting eslint-bridge server at port 33205
16:54:55.837 DEBUG: eslint-bridge server is running at port 33205
16:54:56.067 DEBUG: Starting server (done) | time=178216ms
16:54:56.135 DEBUG: Using generated tsconfig.json file /usr/src/.scannerwork/.sonartmp/11349542101882490689.tmp
16:54:56.158 DEBUG: Analysis of unchanged files will not be skipped (current analysis requires all files to be analyzed)

Here is the Exception from SonarQube version 8.9

ERROR: eslint-bridge Node.js process is unresponsive. This is most likely caused by process running out of memory. Consider setting sonar.javascript.node.maxspace to higher value (e.g. 4096).
ERROR: Failure during analysis, Node.js command to start eslint-bridge was: node --max-old-space-size=6144 /usr/src/.scannerwork/.sonartmp/eslint-bridge-bundle/package/bin/server 41115 127.0.0.1 /usr/src/.scannerwork true false
java.lang.IllegalStateException: eslint-bridge is unresponsive
        at org.sonar.plugins.javascript.eslint.EslintBridgeServerImpl.request(EslintBridgeServerImpl.java:305)
        at org.sonar.plugins.javascript.eslint.EslintBridgeServerImpl.createProgram(EslintBridgeServerImpl.java:377)
        at org.sonar.plugins.javascript.eslint.AnalysisWithProgram.analyzeFiles(AnalysisWithProgram.java:96)
        at org.sonar.plugins.javascript.eslint.TypeScriptSensor.analyzeFiles(TypeScriptSensor.java:95)
        at org.sonar.plugins.javascript.eslint.AbstractEslintSensor.execute(AbstractEslintSensor.java:69)
        at org.sonar.scanner.sensor.AbstractSensorWrapper.analyse(AbstractSensorWrapper.java:64)
        at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:88)
        at org.sonar.scanner.sensor.ModuleSensorsExecutor.lambda$execute$1(ModuleSensorsExecutor.java:61)
        at org.sonar.scanner.sensor.ModuleSensorsExecutor.withModuleStrategy(ModuleSensorsExecutor.java:79)
        at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:61)
        at org.sonar.scanner.scan.SpringModuleScanContainer.doAfterStart(SpringModuleScanContainer.java:82)
        at org.sonar.core.platform.SpringComponentContainer.startComponents(SpringComponentContainer.java:188)
        at org.sonar.core.platform.SpringComponentContainer.execute(SpringComponentContainer.java:167)
        at org.sonar.scanner.scan.SpringProjectScanContainer.scan(SpringProjectScanContainer.java:403)
        at org.sonar.scanner.scan.SpringProjectScanContainer.scanRecursively(SpringProjectScanContainer.java:399)
        at org.sonar.scanner.scan.SpringProjectScanContainer.doAfterStart(SpringProjectScanContainer.java:368)
        at org.sonar.core.platform.SpringComponentContainer.startComponents(SpringComponentContainer.java:188)
        at org.sonar.core.platform.SpringComponentContainer.execute(SpringComponentContainer.java:167)
        at org.sonar.scanner.bootstrap.SpringGlobalContainer.doAfterStart(SpringGlobalContainer.java:137)
        at org.sonar.core.platform.SpringComponentContainer.startComponents(SpringComponentContainer.java:188)
        at org.sonar.core.platform.SpringComponentContainer.execute(SpringComponentContainer.java:167)
        at org.sonar.batch.bootstrapper.Batch.doExecute(Batch.java:72)
        at org.sonar.batch.bootstrapper.Batch.execute(Batch.java:66)
        at org.sonarsource.scanner.api.internal.batch.BatchIsolatedLauncher.execute(BatchIsolatedLauncher.java:46)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        at org.sonarsource.scanner.api.internal.IsolatedLauncherProxy.invoke(IsolatedLauncherProxy.java:60)
        at com.sun.proxy.$Proxy0.execute(Unknown Source)
        at org.sonarsource.scanner.api.EmbeddedScanner.doExecute(EmbeddedScanner.java:189)
        at org.sonarsource.scanner.api.EmbeddedScanner.execute(EmbeddedScanner.java:138)
        at org.sonarsource.scanner.cli.Main.execute(Main.java:126)
        at org.sonarsource.scanner.cli.Main.execute(Main.java:81)
        at org.sonarsource.scanner.cli.Main.main(Main.java:62)
Caused by: java.net.http.HttpTimeoutException: request timed out
        at java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:559)
        at java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:119)
        at org.sonar.plugins.javascript.eslint.EslintBridgeServerImpl.request(EslintBridgeServerImpl.java:297)
        ... 34 common frames omitted

Both the scanner VM and Server VM are on our internal network. Please let me know what else we can check to get this working.

2

Hey there.

Congratulations on working on your upgrade! SonarQube v8.1 is old!

First things first, I would avoid setting this parameter for now:

Second, I would suggest taking a very small sample project and seeing if you can get it analyzed successfully (as opposed to your 1500+ file project). Something like this beginners typescript tutorial on GitHub. This will help us understand where the problem is (the size of the project? or the analysis of any project?)

1 Like
3

Hey Colin,

Sorry for the delay in getting back to you. I cloned the project you mentioned and was able to get it to analyze using the test SonarQube v 10.3 instance I spun up using the Docker container sonarscanner. version 5.0.1. Log output attached.

scan results.txt (6.9 KB)

Let me know what you want me to try next?

4

Thanks. It looks like you’re still facing a very long analysis time:

INFO: Sensor JavaScript/TypeScript analysis [javascript] (done) | time=1268638ms

(This translates to 21 minutes).

I would guess that most of the time is being spent starting up the eslint-bridge. You could confirm this by running the scanner in DEBUG mode (sonar-scanner -X).

Sorry for not making this clear in the instructions before – I thought you were already running in DEBUG mode by default, since your previous logs contained timestamps. :smiley:

1 Like
5

No problem. We had been using sonar.verbose=true in our custom project’s sonar-project.properties file which is why you saw that, but wanted to rule out anything in that file causing issues, so ran the scan without debug on.

Attaching updated results with debug enabled.

sample-project-scan-result-with-debug.txt (113.1 KB)

6

Well, this is definitely taking quite a lot of time.

15:28:48.714 DEBUG: Deploying bundle
15:28:48.714 DEBUG: Deploying the bridge server into /usr/src/.scannerwork/.sonartmp/bridge-bundle
15:38:46.257 DEBUG: Deploying bundle (done) | time=597543ms

All that’s really happening here is that a file is being unzipped. Could there be some software (such as security software) making this painfully slow?

7

Checking with the infrastructure team, in the meantime, I will see if there is another system we can trigger from to rule this out.

1 Like
8

Sorry for the delay, my multiple attempts to get this working have ended up in dead ends, so working through some other channels to stand this up to rule that out.