Split detekt in different tasks #6085
Replies: 2 comments 2 replies
-
I am not sure I understand enough about the inner workings of gradle but it sounds quite nice. I really like to idea to run detekt and store the findings as task output and generate the baseline and reports based on that output.
Does that mean we would have a task |
Beta Was this translation helpful? Give feedback.
-
Is this actually a problem though? CLI should theoretically support everything the Gradle plugin does. I do agree this should change though, probably Gradle plugin should integrate with detekt-tooling instead - I understand the intention is for that to be the primary integration point for all clients, and is used by CLI and IntelliJ plugin already. This could be added to the detekt 2.0 list as its own item. RE: config check, analysis, report - I don't agree that config check needs its own task, that should be a very quick operation, so there won't be much value splitting that out. The analysis & reporting can be split though and like you say we need to serialise the detekt findings as an analysis output, for this, as well as report merging. However I agree with the above comment. This will lead to an explosion of tasks and confusion for users. If we have a TXT, HTML, XML, MD, SARIF & console report task generated for every single analysis task it's going to get completely out of hand and confusing for users. We need serialisation for report merging but I don't know about the usability of this approach. |
Beta Was this translation helpful? Give feedback.
-
Right now detekt is a single unit of execution. I think that for 2.0 we should change 2 mayor things.
First: We shouldn't execute the
cli
from the Gradle Plugin. Those two should be two different clients of the same code. They shouldn't depend one on each other. Right now this creates us the problems that to support something on the Gradle Plugin we first need to implement it on thecli
.Second: Detekt should provide a set of tools and each client should compose them to archieve the desired behaviour. My idea is to have a function that checks if the configuration is correct or not, other to analyze the code and create a report and another(s) to generate the desired output for the user (given a report). The idea is that the clients (
cli
, Gradle Plugin, Maven, bazel...) should implement the coordination of these functions to make it work as expected.The reasons I have to propouse this change:
cli
all of those task will be executed sequentiallyhtml
report on local? No problem! Really fast too because you can download the build-cache for the slow task of detekt and just generate the html report on local.UP-TO-DATE
.What I think we need to work on to make this happen:
class Findings
containts references to PSI elements. That's difficult to serialize.cli
would pass it directly to the reporters but the Gradle Plugin will call the serializer and on the other tasks call the deserializer.I would like to hear your feedback :)
Beta Was this translation helpful? Give feedback.
All reactions