RFC: detekt Gradle task defaults

[3flex]

Expected Behavior

detekt configures itself to run a sane set of default analysis tasks when running the check or detekt task (TBC which one we link to, but that's a separate thing).

I'd consider a "standard" set of tasks to analyse all default source sets for the given target, using type resolution where available. For example:

1. JVM: main & test source sets by analysing compilations.
2. Android: main, test & androidTest source sets for release build type by analysing compilations.
3. JS: main & test source sets by analysing source sets since we don't currently have type and symbols solving for non-JVM targets.
4. KMP non-JVM: main & test source sets by analysing source sets since we don't currently have type and symbols solving for non-JVM targets.

Current Behavior

The detekt plain task checks main & test source source sets without type solving. This falls short:

1. JVM should analyse compilations by default
2. Android should analyse compilations by default and include androidTest source set as well
3. JS is OK as is
4. Non-JVM targets in KMP are missed because no source set is named main or test by default

Context

As a first step we can wire up tasks to detekt and retire the plain task. This uplifts analysis capability that's run by default when detekt or check tasks are run. This will allow further refactoring of the Gradle plugin. Configuring the linked tasks can be done separately (lots of considerations there... do we make it a simple list of strings to include, or have helpers for compilations, targets, variants, build types and flavors (most of which are target-specific).

[BraisGabin]

Android: main, test & androidTest source sets for release build type by analysing compilations.

Instead of release we should use the "default variant" as described at #6232. But I think that even this was just an "example" and not the main purpose of this PR.

Also, what will happen with the plain detekt on JVM, for example? Would we create a new task or would we not even create a task for them? I think that we shouldn't lose "plain detekt". It is clearly less powerful than the one with type-solving but it is also way faster so I cab see use cases to use that one.

Apart from that I agree with the proposal.

[3flex]

Instead of release we should use the "default variant"

The advantage of not doing that is we don't need to dig into the Android DSL to figure that out. "release" is a sensible default and in line with the rest of the defaults. But we have a separate issue to track that enhancement anyway as you said.

It's also only supported on Android applications and libraries, but not on dynamic features or test product flavors, which makes things a bit trickier.

I think that we shouldn't lose "plain detekt". It is clearly less powerful than the one with type-solving but it is also way faster so I cab see use cases to use that one.

./gradlew detektMainSourceSet detektTestSourceSet (or equivalent for the platform type being used). The capability is still there to run easily without type analysis.

[BraisGabin]

All clear! So I agree with this proposal.

I still think that "default variant" would be the best option but let's keep that for the other issue :)

[cortinico]

Generally agree with the proposal 👍 Just one minor questions:

As a first step we can wire up tasks to detekt and retire the plain task.

How are we going to handle the scenario for users that want to disable TR? I suppose that's going to be a property on the detekt extension that folks can configure?

[3flex]

There are the xSourceSet tasks for that.

The only thing missing would then be Gradle Kotlin DSL scripts which could either be a special task we set up in the plugin, or provide instructions to create a custom task.

So rather than a toggle to enable/disable TR, both sets of tasks are always registered, and we need a way to configure which ones are linked to the lifecycle tasks (and that config should be on the extension).

There are still a few bits to build out.

[cortinico]

and we need a way to configure which ones are linked to the lifecycle tasks (and that config should be on the extension).

Ah I see. That also makes sense then 👍