Hello @Rus1an ,
Let’s try to exclude the hidden files. Please, might you add sonar.scanner.excludeHiddenFiles=true besides sonar.scm.exclusions.disabled=true and SONAR_SCANNER_JAVA_OPTS?
Cheers,
Javier
With sonar.scanner.excludeHiddenFiles=true build was successful. I’ll provide you logs, so you can compare with failed scan. So I think the reason of OOM in some of hidden files, right?
So what are our next steps?
Logs:
oom_excludeHiddenFiles.txt (24.1 MB)
Thanks for verifying that it works with the flag.
Because the logs were cut off on run where the scanner run into an OOM, it’s difficult to say which files are responsible.
For now the best idea is to leave the flag sonar.scanner.excludeHiddenFiles=true on for this project.
In the meantime I’m working on an improvement for the scanner, to reduce the memory requirements for the hidden file indexing.
It should also help in your case.
I’ll come back to this thread once it’s deployed on SQC.
Thank you for reply.
Just to make sure that I understand correctly. What does mean “hidden files” for SonarCloud scanner? Are these files that start with dot (.), which are typically considered hidden on Unix-like systems? Are these files are located in our project?
Exactly, on Unix-like systems hidden files are those starting with a dot.
Those files are located inside your project, and judging from the logs are generated during build time inside the node_modules folder. (At least the bulk of them, maybe you have some other hidden files inside a .github folder or similar)
If generated during the build time, they’re excluded from the analysis by the scm.
At the moment we temporarily save some data on these files during the run of the scanner (mainly if they’re hidden or not), and in your specific setup it lead to too much stress on the memory.
@Rus1an We deployed the improvement on SQC and in cases like yours the scanner should need less memory.
Could you verify if your scan is successful without the additional flag?
I ran scan without sonar.scanner.excludeHiddenFiles setting and it was successful. But it took 27 minutes though average duration with setting is about 6-7 minutes. Do you need logs of the scan?
That would be great! If possible debug logs by setting sonar.verbose=true 
Hi @jonas.wielage
If I set sonar.verbose=true, pipeline is failed with timeout. So I’m providing you logs from Friday’s run when it was successful but verbose mode was disabled.
sonar_after_fix.txt (836.7 KB)
Thanks for the logs!
Looking at them, most of the time is spent preprocessing the files, even if they’re discarded at a later stage. I see that this is the case for approximately 33,5 million files.
2025-07-18T12:16:18.1063079Z 12:16:18.105 INFO 7 languages detected in 4542 preprocessed files (done) | time=1309337ms
2025-07-18T12:16:18.1064251Z 12:16:18.105 INFO 32287133 files ignored because of inclusion/exclusion patterns
2025-07-18T12:16:18.1068692Z 12:16:18.105 INFO 1420859 files ignored because of scm ignore settings
At the moment I don’t see a better way of configuring your analysis and sonar.scanner.excludeHiddenFiles is your best option of reducing the analysis time.
The only downside this has is a missing secrets analysis for hidden files.
If there are some specific hidden files / folders you still absolutely want to have in the secrets analysis, you should be able to add the path additionally to sonar.sources.
Let me know if you need help with that.
I’ll discuss internally to see if we can improve the preprocessing behavior for use cases like yours!
Best
@Rus1an We created an internal ticket to improve the duration it takes to run the preproccessing. While I can’t give a concrete timeline for the fix, our goal is to work on it during the next hardening for the scanner.