one of our project (nodejs + cloudformation) scan pipeline is running in systematic OOM of the Sonar Scanner after the last Azure DevOps extension update (1.36.0).
I tried to set the SONAR_SCANNER_OPTS to -Xmx2048M with no benefits.
From the pipeline logs I noticed that, running the pipeline from the same commit-id, after the update there’s some difference.
Sorry for the late response. Thank you for your report. The files we have in the logs are. What size are these files and are they automatically generated or part of the project?
We have adapted the text analyzer to also detect secrets. This means that more files are now included in the analysis. In your particular case, we need to see if these files are actually relevant for the analysis. If they are not, you can exclude them from the analysis. And we can try to identify a pattern to exclude these files from the scope.
I’m not completely sure to understand what you actually mean. The log files I’ve shown are generated by the CI/CD pipelines we are using to build our applications and where the SonarCloud scan is performed. They are not part of the git repo being scanned, they are just the logs of the sonar-cloud scanner while running…
If you contact me in a private conversation I can provide them and even run them in debug mode.
In the meantime we are experiencing more and more OOM error in other pipelines. The last one is a pretty big typescript / react / react-native repository what is now basically impossible to scan anymore…
Is there a way to make the scanner behave in the “old” way and hopefully avoid the OOM?
We had similar issues in the past and we were able to disable some new feature causing similar issues (sonar.internal.analysis.dbd=false).
we decided to change the predicate to select files for the secret analysis. After this fix it should analyze the same files as before the update. We plan to release this fix soon. I will keep you up-to-date.