Hi,
Heard about this issue from a friend so did some digging. Was able to replicate the issue on my mac (local analysis) and got a profile showing the majority of the slowdown was during the ZipOutputStream.putNextEntry, closeEntry and close. This got me thinking a little and looking at how the analysis works…
From my understanding, sonarScanner will work in a .sonar-scanner folder in the project working folder, usually mounted to /usr/src (although the github action mounts to github/workspace) This folder is being mounted through the docker volume command, which on mac specifically is known to have performance issues, and any extensive work across a docker bind-mount is likely to include some performance issues.
When sonar scanner creates a decent number of files (5,200 in a random example project) and then begins to iterate each file to add to a zip (sonarqube/ZipUtils.java at master · SonarSource/sonarqube · GitHub) and therefore creating and closing the stream on each file, any penalty with working in a bind-mount will begin to get noticeable.
So I’m wondering if something similar is happening here. Github Action owned runners may not present the issue as the mount performance may be optimised however the self-hosted, node runners as defined in the first post might be impacted by this.
So question to the SonarScanner - is there a way to customise the working directory to be inside the container file system, something like /tmp/.sonar-scanner instead of the project directory to avoid working in the mount-bind path? If so then at a minimum this would help confirm that the mount-bind is the issue, instead of something else.