hm... probably I was not writing it clearly enough...

# detekt

[robstoll]

hm... probably I was not writing it clearly enough. I don't want to suppress rules. I want to configure them differently for different src

[mauin]

What I can think of (with RC8) to define different profiles with different input paths. Then you can give every profile a completely different config and execute the different profiles independently

[mauin]

However that's going to be quite a hassle to set up (and the profile API was also removed in RC9 and above...)

[mauin]

In RC9 you could set up different detekt task (extending from the default one) and giving them each different input paths and configs.

[robstoll]

I see, thanks. In this case I'll wait until we migrate to a newer gradle version. I have one more follow up question though. Is it possible to merge multiple detekt xml reports? I would like to use it in conjunction with Sonar

[mauin]

For sonar also look at the detekt sonar integration. But merging the xml reports should also be fairly trivial

[robstoll]

nice 🙂

[Mike]

As long as you have access to install plugins to Sonarqube from source, you’re good to go. Fairly easy to configure.

I documented setting it up here https://docs.sonarqube.org/display/PLUG/SonarKotlin

But it appears Sonarqube now has a Kotlin plugin that claims it will import detekt reports. Haven’t done anything with it yet, so have no personal experience.

https://docs.sonarqube.org/display/PLUG/SonarKotlin

[mauin]

Interesting. Would be good to know how it compares to the Detekt plugin for Sonar. cc @Artur Bosch

[Mike]

Just looked it up, so don’t know, but also curious. Currently using Detekt provided Sonarqube plugin.

Wonder if they’re reimplementing all the rules or how they’re doing analysis. Nothing obvious in the docs page for the plugin.

[robstoll]

Unfortunately I don't have access to the sonar server, I am using SonarCloud for opensource projects.
I am using the import. It works well, imports all detekt issues as you would expect it.

[robstoll]

It seems SonarSource provides a few rules on its own and unfortunately some of them are duplicates of detekt (same same but different as with java + checkstyle + Sonar kind of)

[Mike]

Looking at issue tracker, I think they’re doing all the work all over again. Disappointing if that’s the case. I REALLY like that Detekt is part of the local build process rather than part of CI.

Ensures the issues get fixed quickly and don’t build up to an insurmountable mountain.

[robstoll]

I am sure SonarSource wants to provide their own sonarLinter in the future. that's at least how it has been with Java and Checkstyle/PMD and the like

[mauin]

@Mike I guess that's also depending on the project setup. Its great that you're running detekt locally at the moment. But running it on CI definitely has its advantages as well.

[Mike]

We use Gradle, so it’s part of the build.gradle and gets run on both local and CI. Definitely agree want backup of CI run.

[mauin]

Is that because you run ./gradlew build/check locally and detekt hooks into that?

[Mike]

exactly.

[Mike]

Using the Detekt gradle plugin so hook it in to check. RC9+ automatically hooks itself into process.

[mauin]

👍

[Artur Bosch]

the official sonar-kotlin plugin runs on a new concept called universal ast. there is an ongoing effort to support ruby, scala, go, kotlin etc as fast as possible. So they created an ast which can be used for all this languages. Now they need to reimplement all rules.

As I understood it, they just allow to import the detekt.xml file. They do not run detekt themself.

[Artur Bosch]

That brings also the need to migrate our plugin away from the name sonar-kotlin? internally we use the name key etc so in practice we cant install both plugins ...

[mauin]

JetBrains already has a UAST (universal AST) that covers both Java and Kotlin and it is what Android Lint is currently using to support rules that can operate on code of both language