[Emigre_]

Sonar doesn't seem to really work in my limited experience. It adds a lot of of time to builds, at least in the cases I've seen, while there are alternate linters or code quality tools capable of doing the same at a fraction of the time. Build times and development speed matter!... They matter a lot. You need a quick feedback loop.

[ars]

I use Sonar all the time, but not during build. It runs live while I'm editing a file. I've not noticed any slowdown at all, and it's certainly a quick feedback loop (it runs when I save the file).

I've found the majority of its suggestions helpful, and the ones that are not I simply ignore.

[nsxwolf]

It adds about 2 minutes to our gitlab pipelines but the major issue with it is when organizations decide failures should prevent merging code to master or even deploying to a QA environment.

That's the real time sink - figuring out how to get past it. It's a lot more than 2 minutes, sometimes even days if it's something you can't work around and have to go through the red tape if your team isn't empowered to take charge of your own pipelines.

[raiyni]

You think 2 minutes is bad, try using fortify. Scans can easily be hours.

[Emigre_]

I should have mentioned that I was referring actually to the continuous integration pipeline, not actually to the build itself. Not very well explained on my side. I've never used it locally myself. I don't really know why the CI setups that were using Sonar I've seen in the past were that slow, to be honest.