Very first automatic analysis fails: analysis ID is AY7C18Km3QnKmbxiH96r

  • ALM used is GitHub
  • CI system used is NA (automatic analysis performed by SonarCloud)
  • Main language of the repository is JavaScript
  • Error observed: the UI reports that Last analysis failed Analysis ID “AY7C18Km3QnKmbxiH96r”
  • Steps to reproduce: this is the very first automatic analysis of the first project within a brand new organisation
  • Workaround: we tried adding the configuration file .sonarcloud.properties in our default branch but it does not help

Our pull requests are successfully analysed but our default branch is not.
As a consequence, we still lack the quality report for the overall project.
Besides the analysis that keeps on failing repeatedly - the ID of last failed analysis is “AY7DacJwvlb8yoCjvAyN” -, we also get the following warning message:

“develop” branch has not been analyzed yet and you have multiple branches already. It looks like it is not your Main Branch, check your configuration.

But we have only one single branch in the Branches screen…
Could you please help us unblock this situation?

Last analysis failed Analysis ID “AY7I6H5L2521o_suCTUY”

Every push to our develop branch triggers a new analysis that fails. But since there is no indication whatsoever on the error that is triggered, waiting for a reply in this forum is basically our only option…

Hi @thomas-jakemeyn, welcome to the community!

But since there is no indication whatsoever on the error that is triggered, waiting for a reply in this forum is basically our only option…

You are absolutely right. As a note, we are actively working at improving this situation, to build the best automatic analysis experience.

Last analysis failed Analysis ID “AY7I6H5L2521o_suCTUY”

Indeed, on your develop branch the analyses hit an internal error.
I’ll continue investigating it, and get back to you.
Thanks in advance for your patience, and all my apologies for the inconvenience.

Claire

Hello Claire,

Thank you for your support!
The tool has been amazing so far, so we really hope to get this fixed.

1 Like

Hi again!

At first sight, it seems the test files may not be configured as such. This can lead to internal errors during the analysis.
I would suggest creating a file named .sonarcloud.properties, with this content (or adding it to the existing file if any):

sonar.tests=test
sonar.exclusions=test/**/*

We added such a file in our develop branch 2 days ago with a similar configuration.

sonar.sources = app/,services/
sonar.exclusions = **/*.spec.*
sonar.tests = test/

Is there something wrong with that configuration?

sonar.sources does not contain the test folder. Moreover, the test files (*.spec.*) that are located in source folders are supposed to be excluded.

Hi @thomas-jakemeyn

Indeed, this configuration looks good.

For some reason that is not clear yet, on your main branch, the analysis hits our internal memory limit of 8GB.
The only workaround we see at this very moment would be to move to CI-based analysis, and to give to your CI worker more than 8GB of memory.

You could also try to play with the sonar.sources and sonar.exclusions to identify if a particular folder or file creates the issue.
That would be extremely useful for us to have this information to improve the behavior and the memory footprint of our software.

Hi @Claire_Villard,

I have restricted the analysis scope to the bare minimum (just the app folder, just the JavaScript code, just the production code) and it still fails…

sonar.sources=app
sonar.inclusions=**/*.js,**/*.jsx,**/*.cjs,**/*.mjs,**/*.ts,**/*.tsx,**/*.cts,**/*.mts
sonar.exclusions=**/*.spec.*
# sonar.tests=test

So it looks like the problem is located in our app folder. The analysis is successful when I add all the other source folders. But as soon as I add app to the scope of the analysis, it fails.

The biggest file in app contains 6K lines of code. But the vast majority of them contain less than 1K lines of code. What are the other criteria that can affect memory footprint on your side?

I tried ignoring the 8 files that are bigger than 100KB but the analysis still fails when I add the app folder.

sonar.javascript.maxFileSize=100

Last analysis failed Analysis ID “AY7RxEB51NDVUtOlrQ6Y”

I noticed that 2 JS files inside app had a white space in their name. I fixed that but the analysis still fails for the app directory.

Last analysis failed Analysis ID “AY7SG2sopMQkD3E6DGw8”

I feel like I am searching for a needle in a haystack. @Claire_Villard can you please give me more precise indications?

Hi @thomas-jakemeyn

Thank you so much for all this data.
I’m still processing our internal logs for all the tests you did this morning :smiley:

That’s super useful, we will come back with more information as soon as we have some!

Hi again,

It appears that the option sonar.javascript.maxFileSize is not used by the part of the scan that is failing, which explains why you couldn’t see any improvement.
I would suggest excluding those files using sonar.exclusions, to completely move them out of the analysis scope.

If there are some subfolders within the app folder, I could suggest excluding some of them, with the goal of narrowing down which specific file or subdirectory may contain something that makes the whole process blow up.

1 Like

For your information, I am now trying to remove the file .sonarcloud.properties and to use UI parameters instead (Project > Administration > General Settings > Analysis Scope).

Moreover, I have connected SonarLint to SonarCloud and I noticed that it also fails with a out of memory. As a consequence, it does not display any information in my VS Code.

1 Like

That’s again useful information!

If there anything interesting in the SonarLint output tab that would help locate the source of the OOM in SonarLint?

So the analysis failed once again with my UI-based configuration of the analysis scope (as expected, but using the UI makes it easier to test various configurations).

Last analysis failed Analysis ID "bd775d0c-79e0-43ff-9e2d-d5a3ba5a8001"

About SonarLint, it looks like the problem could be related to the activation of type-checking for JavaScript files.

[Info  - 16:41:35.760] Turning on type-checking of JavaScript files
[Info  - 16:41:35.897] Found 0 tsconfig.json file(s): []
[Debug - 16:41:35.904] Using generated tsconfig.json file using wildcards [/var/folders/fc/gy32v6m122q_mrysjxfs53xw0000gn/T/tmp-72746-N60Afm5QNHwr]
[Debug - 16:41:35.904] Will use AnalysisWithWatchProgram because we are in SonarLint context
[Debug - 16:41:35.904] Initializing org.sonar.plugins.javascript.bridge.AnalysisWithWatchProgram
[Debug - 16:41:36.077] tsconfig /var/folders/fc/gy32v6m122q_mrysjxfs53xw0000gn/T/tmp-72746-N60Afm5QNHwr files [...]
...
[Trace - 16:41:49.074] Pinging the bridge server
[Trace - 16:41:54.074] Pinging the bridge server
[Debug - 16:41:55.986] The worker thread failed: Error [ERR_WORKER_OUT_OF_MEMORY]: Worker terminated due to reaching memory limit: JS heap out of memory
[Error - 16:41:55.986] The analysis will stop due to the Node.js process running out of memory (heap size limit 4144 MB)
[Error - 16:41:55.986] You can see how Node.js heap usage evolves during analysis with "sonar.javascript.node.debugMemory=true"
[Error - 16:41:55.986] Try setting "sonar.javascript.node.maxspace" to a higher value to increase Node.js heap size limit
[Error - 16:41:55.986] If the problem persists, please report the issue at https://community.sonarsource.com
[Debug - 16:41:55.986] Shutting down the bridge server due to failure
[Debug - 16:41:55.986] The worker thread exited with code 1
[Debug - 16:41:55.987] The bridge server shut down
[Error - 16:41:55.989] Failure during analysis
[Error - 16:41:55.989] java.lang.IllegalStateException: The bridge server is unresponsive
	at org.sonar.plugins.javascript.bridge.BridgeServerImpl.request(BridgeServerImpl.java:403)
	at org.sonar.plugins.javascript.bridge.BridgeServerImpl.analyzeJavaScript(BridgeServerImpl.java:361)
	at org.sonar.plugins.javascript.bridge.AnalysisWithWatchProgram.analyze(AnalysisWithWatchProgram.java:155)
	at org.sonar.plugins.javascript.bridge.AnalysisWithWatchProgram.analyzeTsConfig(AnalysisWithWatchProgram.java:130)
	at org.sonar.plugins.javascript.bridge.AnalysisWithWatchProgram.analyzeFiles(AnalysisWithWatchProgram.java:79)
	at org.sonar.plugins.javascript.bridge.JsTsSensor.analyzeFiles(JsTsSensor.java:132)

The list of files there is just huge and seems to ignore the inclusions and the exclusions that have been configured. I need to allocate 12Gb of RAM to make it work!

Could this be related somehow? Improve logging of JavaScript files type-checking in SonarLint context · Issue #4186 · SonarSource/SonarJS · GitHub

I tried creating a dummy tsconfig.json in my project (which is not a TypeScript project) and there is no memory issue anymore. Unfortunately, no problem is reported by SonarLint although the open file does contain some.

I have found this discussion: SonarCloud JavaScript Analysis Super Slow.
I have followed the workaround that it describes, aka creating a fake tsconfig.sonar.json.

{
	"include": [
		"<same includes as for SonarCloud>"
	],
	"exclude": [
		"<same excludes as for SonarCloud>"
	],
	"compilerOptions": { "allowJs": true, "noImplicitAny": true }
}

I have then configured SonarLint to use that file.

  "sonarlint.analyzerProperties": {
    "sonar.typescript.tsconfigPaths": "tsconfig.sonar.json"
  },

This fixes the problem for SonarLint: it properly reports the problems in my VS Code without allocating more memory. I am now testing if the same solution also fixes the analysis of the app folder on SonarCloud…