Automatic Multi-Language Support: It appears that this update was automatically applied across all of our repositories, enabling multi-language support by default. This has impacted our setup significantly. We are using GitHub with GitHub Actions (GHA) for our builds and have a monorepo configuration where backend and frontend code were scanned as separate projects. Now, with this automatic update, the backend project is scanning everything, causing us to effectively pay for front-end lines twice.
Temp Files Scanned as Source Code: Additionally, we’ve noticed that certain temporary files, such as test run reports and coverage.xml, are now being treated as source code and scanned by SonarCloud. This has drastically increased the size of our projects by 5 to 10 times, which is rapidly consuming our license limits.
As a result one of our projects overnight became 380k LOC from 50k LOC.
Current Workaround:
We’ve found that setting the sonar.scanner.scanAll=false property helps mitigate the issue. However, we are frustrated that we now have to manually update every project to resolve an issue that wasn’t present before this update.
Is there any way to revert this behavior or handle it more efficiently without manually adjusting all of our projects? We would greatly appreciate any guidance or solutions that can help us avoid these unintended consequences.
Hi there, @akorkoshko
First, thank you for your frank feedback.
Second, I want to apologize for the disturbance this is causing.
On the temp files and coverage files being scanned, this is an oversight on our part and we are looking into ways to fix this, as well as other undesired behaviors.
On the “on by default” side of things, our discovery has made it clear that the scanner’s previous behavior was causing many issues for new users, leading to bad experiences for newcomers (not finding a way to analyze such projects, having to modify csproj files for the sole purpose of analyzing all the code, not being able to use the mono repo solution because of their SQ edition…).
We decided to make this an opt-out feature with a major version change because of that. Frankly the scanner for .NET should always have worked this way. If we could have found a way to make it more seamless for cases such as yours, we would have, but we cannot detect monorepo setups in SQ/SC while scanning, so we took the decision to make this change that requires a one-time change of existing pipelines to make setting up all new projects easier going forward.
Again, I understand this is a (sometimes not so small) inconvenience, but in the long run I still believe making this the default is the better decision for the vast majority of users.
That being said, in retrospect, a longer heads-up period about what was coming might have been warranted for cases such as yours. I will definitely take that experience into account next time we approach a change like this.