Let's rethink out Gradle tasks #3364
Replies: 2 comments
-
Generally agree on your idea 👌 On the Baseline/Report side, I believe we should strive for having a per-module solution + merging them. Specifically I think we should clarify how we merge between modules and between variants/srcset. I remember having a lot of discussion with colleagues and collaborators and they all mentioned the pain point of having to collect multiple reports/baselines. Definitely having one top level output would be the end goal (and the result should be aggregated among all the JVM/Android modules available). |
Beta Was this translation helpful? Give feedback.
-
I added the task to merge all reports into a top-level report to #3360. |
Beta Was this translation helpful? Give feedback.
-
The current tasks that we expose in gradle are a bit missleading. The reason is that detekt grew up and the first task doesn't allow type solving. And the we added Android compatibility with new tasks. I think that we should rethink those tasks for 2.0 (or maybe we can implement them in 1.0 and just remove the old ones in 2.0).
Initial idea
We just need 4 main tasks:
detektCheck
- runs detekt with type solving. It never reformat code. It will run detekt in all the source sets (jvm) or build variants (android). So it will be a meta task that adds all the tasks of all the source sets/build variants.detektFix
- runs the rules that are correctable with the correctable flag. It never fails nor creates any report. It just fixes all the issues that it can. It will be a meta task asdetektCheck
. This could even help with Detekt crash on autoCorrect property #3250.detektBaseline
- generates the baselinedetektConfiguration
- generates the configurationChanllanges
Reports
If we run
./gradlew :module:detektCheck
we should generate only one report per:module
:So, maybe, an idea is to change how we generate the reports. We could generate a SARIF report per buildVariant/sourceSet but save it in the directory
build/intermediates
orbuild/detekt/intermediates
or something similar. And then in thedetektCheck
meta task read all those files and create a merged report. I don't know how it will look like in xml but in html we could add a label to point out if that issue appears in all the buildVariants/soruceSets or just in some of them. As a bonus point this will help us A LOT with the cacheability of our tasks.Another challage is that if we run
./gradlew detektCheck
we should get one general report. If we implement the previous solution this would be kind of easy.Baseline
This is similar as the report challange but it's probably easy to solve. Right now we generate far too much baselines. Here I don't know which is the correct solution: one baseline for all the project or one baseline per module. I vore more for the second but, in any case it should be just one and no one per buildVariant/sourceSet.
I think that the solution here could be the same as the one in reports. Each subtask specific to one buildVariant/sourceSet will generate the baseline in an
intermediates
directory and then the meta task will merge them in the actual file.What do you think? This are just my ideas and I know little about how a JVM project is setup so please correct the parts that I think that I'm wrong. Are we missing other feature in our current gradle plugin that we should implement?
Beta Was this translation helpful? Give feedback.
All reactions