I have some projects written in Kotlin hosted on GitHub.
For example this one.
It’s analyzed by SonarCloud.io with the AutoScan feature.
That’s fine, because Github Actions take CI minutes and I plan for a private project where these will have a limit. I noticed that SonarCloud Scan with Gradle takes some minutes.
Now I want to include the Detekt linter.
SonarQube allows to install plugins, SonarCloud does not.
Of course I found this page:
But I don’t know how I can use that information to include Detekt issues in SonarCloud.
Do I have to run “gradle detekt” as GitHub Action?
How does SonarCloud find this report then?
Or do I absolutely need GitHub Actions to include Detekt?
So I’m asking how a GitHub + SonarCloud setup must be configured to include Detekt issues.
I believe your understood correctly the current limitations of the AutoScan feature.
If you want to import Detekt issues into SonarCloud, you need to run yourself Detekt (through a GitHub Action is indeed a good idea in your case).
Once you have your Detekt report generated, you will need a file .sonarcloud.properties at the root of your project and reference the location where the Detekt report is generated through the property sonar.kotlin.detekt.reportPaths.
Ideally, we would expect you don’t need Detekt at all and you can rely only on what is provided by SonarCloud. We are not yet at this stage with the 43 Kotlin rules provided by SonarCloud, but recently this has been discussed at SonarSource. You can definitely help us on this and this is why I have two questions for you if you know well Detekt:
what are the 5 more valuable rules provided by Detekt?
what are the 5 less valuable rules (generating a lot of FPs for example) provided by Detekt?
At my old company I worked four years with SonarQube on a Java project and I love this tool. So I want to use SonarCloud at my new company.
Now the problem ist that the GitHub Action triggering the SonarQube analysis takes some times. 8 Minutes for a really small project. At my old really big project (with a million lines of code) the analysis runs between 45 minutes and up to 3h. So this will certainly waste CI minutes. Btw: Will you work on the performance here?
It should be possible to run Detekt via Gradle plugin as GitHub Action. But the problem is that this will not write local files anywhere - GitHub Actions are self contained. So there is no report directory SonarCloud AutoScan could look into.
Do you have a solution for that?
The GitHub Action could create a ZIP file that contains the report directory as artifact.
But how will SonarCloud find these results?
I think I need help here to understand how SonarCloud, Detekt and a GitHub Action would work together (if I’m not running the SonarQube Gradle plugin).
I will get back to you with a feedback which Detekt rules I need and which are not so useful.
For the performance point, I suggest that you open a new thread so we can exchange only on that. If you can provide an open source reproducer that would help.
For you topic about Detekt integration, I believe the best option you have today is to rely only on GitHub Actions and forget about AutoScan. You put everything into a single GitHub Action that:
run Detekt and output a file compatible with sonar.kotlin.detekt.reportPaths
you run SonarCloud (there is a tutorial about how to setup the SonarCloud part of your GitHub action once you click on “Analyze new project” in SonarCloud)
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?
Kind regards,
Stefan
P.S.:
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.
Potentials bugs
“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.
