Hi everyone. I'm hoping to get some collective wisdom on a persistent issue we're hitting in our CI pipeline.
We're running SonarScanner for a large, monolithic Go codebase (several million lines). Our analysis consistently fails during the scanning phase with out-of-memory errors, even after we've allocated what we thought were generous resources. The scanner process is getting killed when it spikes past 8GB RAM, which is causing failed builds and a lot of frustration for the team.
We're using the official SonarScanner CLI (not the Maven/Gradle plugins) in a Kubernetes pod. We've tried tuning the standard `-Xmx` settings for the JVM, and we've set `SONAR_SCANNER_OPTS` with increased heap space. While that helps a bit, the memory consumption during the Go analysis itself seems to balloon unpredictably. We're not seeing this with our smaller services, only this large project.
Has anyone successfully scaled SonarQube analysis for a massive Go project? I'm particularly interested in:
* Any scanner configuration flags specific to Go that reduce memory footprint.
* Whether splitting the analysis or using a different scanner approach helped.
* If there are known issues with certain versions of the Go plugin or scanner.
I'd also welcome any general strategies for managing scanner resources in memory-constrained environments. We're committed to the quality gates, but the infrastructure overhead is becoming a real blocker.
Thanks in advance for any insights you can share.
~ Amy