Task redundancy

[mgroth0]

I have just discovered that I am currently executing redundant Detekt tasks.

Expected Behavior

There should be a typesafe way to depend on all normal Detekt tasks for a module. By normal, I just mean running Detekt on all kotlin code, but not any of that baseline stuff.

The way I try to do this is myTask.dependsOn(tasks.withType<Detekt>()). I expect this will simply make myTask run only after Detekt has executed on all my code.

Observed Behavior

I just discovered that in some projects I have 3 detekt tasks: detektMain, detektTest, and detekt. And I didn't even realize this before, but detekt is actually running all the rules again redundandly which already run in detektMain and detektTest. So all rules end up getting executed twice.

Steps to Reproduce

1. I observed this issue on my branch at e6f9de9
2. The module I observed it on is not Kotlin Multiplatform but rather just a classic java-style module with a main and test source set
3. I have some custom output which uses the task name as the root folder for the output. So I see duplicate reports inside of the detekt and detektMain folder, and also duplicates from detektTest in detekt and that tells me the rules ran twice, redundantly.

Context

The central issue here is that I expected myTask.dependsOn(tasks.withType<Detekt>()) to simply allow me to make sure detekt is running on every source set, but I did not realize that it was also making detekt redundantly rerun analysis. As a workaround maybe I could disable the detekt task since detektMain and detektTest seem to cover everything, but I think a better solution could be:

1. To redesign the set of tasks (which i know is underway right now)
   or
2. To provide some sort of API to help users who want to ensure they are running Detekt on all kotlin files in every target and source set, but without running anything redundantly. Not sure what this API would look like, but I've seen gradle plugins carry references to specific TaskProvider instances before, so maybe something with that.

[mgroth0]

related to #6973

[mgroth0]

Also related #5947

[3flex]

There is going to be some overlap in compilation analysis because different compilations can share source files, but we should have some sensible defaults when running the detekt or check tasks that minimises instances of scanning the same file more than once.

I'm actively working on this.

[cortinico]

As a workaround maybe I could disable the detekt task since detektMain and detektTest seem to cover everything, but I think a better solution could be:

You're right, this is a known problem.

As @3flex mentioned, we're redesigning the task graph to handle scenarios exactly like this one.