okay, then it must be a GitHub Action for now.
Small projects with just 1.5k lines of code already take their 5 minutes for analysis.
With a million lines of code this can take about an hour.
Another idea for this:
Why not enable the Gradle SonarQube plugin to just send external linter reports to an SonarQube instance without perfoming the actual scan? Now AutoScan and the Gradle way are mutual exclusive, but I don’t see why this must be that way.
What do you think?
Here is a list of Detekt lints I miss in SonarQube:
Proper Exception handling rules
like “SwallowedException” / “EmptyCatchBlock” / “PrintStackTrace”
All naming rules
“ClassNaming”, “FunctionNaming”, “VariableNaming” and the like.
For some reason only methods and local variables are checked.
Providing rules for everything should be a low hangig fruit and a priority.
“UnsafeCallOnNullableType” and similar classics from the Java world.
Lints that are not so important belong to the “formatting” category.
These should also be implemented in Sonar one day, but if you use IDEA with formatter usually these don’t raise.
As I see the most existing rules address complexity - length of classes, methods, count of methods, etc.
Detekt has some more and it should be useful to copy them.
I use SonarQube most of the to give me hints to potential bugs. And thanks to your great tool many of them did not reach production at my Java projects.
Rules that hard limit number of attributes and so on are not that useful for me because there are always situations where you need to add a feature, add the 11th attribut and won’t be in the situation to trigger a redesign. My point of view is that there should be metrics to show that, but not necessarly build breaking lints.
I hope this input is useful for you.