-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Detekt Integration - Phase.1 #13996
Detekt Integration - Phase.1 #13996
Conversation
This commit adds 'Detekt' version '1.15.0', that bundles with Kotlin version '1.4.10', which is the Kotlin version currently utilised within this repo. The next version of 'Detekt' is the '1.16.0-RC1', which updates Kotlin to '1.4.21'. But, this is unnecessary, at the moment, for this repo. Also, it is still a release candidate. In addition to that, this commit configures 'Detekt' using the default configuration, defaulting all options to 'false' for ease of integrating the tool to the repo. The 'detekt.yml' file was automatically generated running the 'detektGenerateConfig' command. This file remained unchanged in order to utilise 'Detekt's' default configuration as a starting point. The only configuration that was updated was the 'warningsAsErrors', which was update to 'true' in order to have all warning being treated as errors by default. Apart from that, the 'detekt-formatting' plugin was also added to this configuration in order to have the 'Formatting' section being reported, alongside all its corresponding formatting violations (currently 45). However, the 'autoCorrect' configuration flag was set to 'false' in order to not have the codebase being automatically reformatted whenever 'Detekt' gets triggered.
This 'Detekt' baseline suppresses the existing issues (880 in total) to have 'Detekt' running as if the codebase has zero issues. This helps to start utilising 'Detekt' immediately without having to worry about the existing issues. Any new issues that will be added to the codebase right after will be reported and the build will fail accordingly.
This 'Circle CI' step differs to the rest since it actually targets a specific module, the 'WordPress' module, instead of running 'Detekt' on all the modules, like the other steps do. This is by design since 'Detekt' is currently configured for the 'WordPress' module only. Locally, every developer will need to also trigger './gradlew WordPress:detekt' instead of './gradlew detekt' as the former will run 'Detekt' on all modules, which is not currently supported.
You can trigger optional UI/connected tests for these changes by visiting CircleCI here. |
You can test the changes on this Pull Request by downloading the APK here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for working on this @ParaskP7!
I've tested the configuration and it seems to work as expected. I've left a couple of comments, let me know what you think.
P.S. I installed the IDE plugin and I created a method with 5 returns statements. The cmd task found the error, should the IDE plugin underline the method or somehow indicate an error?
parallel = false | ||
debug = false | ||
reports { | ||
html.enabled = true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💡 Idea: Unless we are planning to use all three formats, I'd personally disabled those we don't need.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👋 @malinajirka !
Yes, I was thinking about that too. I choose to not disable any of the formats for two reasons:
- The output files are very small anyway, thus there will not be a build overhead,
- I don't know how and which format our CI will going to be using in the future, for reporting purposes, so I enabled all possible formats to make it easier for future integration.
PS: We can definitely have only one of those enabled if you like. Let me know which one you prefer. @loremattei
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think xml
is enough for CI as it's the one used by the plugin we use to post comments on PRs. 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Many thanks for adding to that @loremattei !
So, since xml
is required by CI, and IMHO html
is a real nice to have locally, to get a nice representation of the issue at hand and how to fix it, I would have those two enabled. This might leave us with only txt
to decide to disable, but even that I suggest to keep it enabled since I find myself sometimes looking at this find to figure what the problem more rapidly. I don't think those files are too much overhead and as such I would have the enabled (at least for now).
@loremattei @malinajirka your thoughts?
PS: I will be fine even if we decide to disable all of them and ending up having xml
the only one being enabled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it doesn't take any significant amount of time, I agree that keeping all of them is fine.
👋 @malinajirka !
Thank you so much for this thorough review and all the comments you left Jirka, much much appreciated! 💪
The IDE plugin should highlight the whole line with yellow color and indicate that this is a warning. You want want to restart your IDE or sync it or the plugin might be misbehaving on its current version or due to the new Detekt version, not sure. However, I also noticed that my IDE wasn't highlighting those warnings for me too yesterday, but skipped the debugging for later. |
This is done in order to align this configuration with the more global root level 'build.gradle' detekt 'autoCorrect = false' configuration.
This is done in order to make it explicit that whatever additional android formatting rule can be applicable is not being ignore. Note that after enabling this formatting flag and running './gradlew WordPress:detekt' there was no new formatting issue reported.
Since code is being merged behind feature flags into 'develop' TODO comments are unavoidable at the moment. In the future, this rule might get enhanced to only allow TODO comments that contain a deadline and have a developer assigned to them. Also, note that the baseline was update to exclude these TODO related forbidden comments.
Also, note that the baseline was update to exclude these enum related magic numbers.
…id into detekt-integration
Two new issues were added to the baseline.
👋 @malinajirka ! I just re-requested your review on this PR, could you please check out my responses per comment and any new commit that fixes what was described. Many thanks in advance! 🙏 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks for the changes and for creating the issue for 2nd phase ;).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for this @ParaskP7!
I tested following the steps you provided and it worked as expected, other than what @malinajirka already noted.
Detekt was configured on the root build.gradle file, within the allprojects { ... } scope. However, I have noticed that the subprojects { ... } is utilised as well for static analysis tools like KtLint. Do I need to add an additional task for Detekt within the subprojects { ... }?
I've never dug into how KtLint was configured, but looking at the Detekt documentation it seems to me that what you did is enough.
The exist a task within the WordPress build.gradle file, called violationCommentsToGitHub. This task has a violations configuration for CheckStyle. Do I need to add something similar for Detekt?
Yes, that task is called on CI and it adds a comment with the violations to the GH PR. It looks like Detekt is supported as well. I think that if we use the default output configuration for the Detekt report, it should pick it up automatically.
👋 @loremattei !
Thank you so much for the review! 🙏 Yeap, @malinajirka was really thorough! ❤️
Thanks for double checking on that, I agree! 🙏
Coolio, let me check on that as well before merging that to |
👋 @loremattei !
I checked the tool (violation-comments-to-github-gradle-plugin) and maybe the below configuration is what we need to have I'll try to push a commit with that configuration with both, some |
…id into detekt-integration
This is done in order to give space to another violation comments configuration, specific to 'Detekt', since the '.xml' path is currently too generic.
This will enable violation comments for 'Detekt'.
👋 @loremattei ! I have been trying to update the PS: I am now going to create a separate
|
…id into detekt-integration
After testing the 'Violation Comments' plugin it seems that the plugin is not working as expected. As thus, any additional configuration is being reverted. This additional configuration will be added back again when the plugin gets back to work a working state. Link: #14051
Seven new issues were added to the baseline.
External Links: Detekt - Detekt Documentation
Internal Link:
paqN3M-eg-p2
(Detekt Integration)Related PR: Showcase
Next Phases: Phase.2 - Phase.3
This PR adds
Detekt
to theWordPress
repo. Detekt is a static code analysis tool for the Kotlin programming language. Detekt does for Kotlin what CheckStyle does for Java, only so much more.To test (🧪 ):
Detekt
has to offer, how it can be configured and utilised.detekt-integration
on a local branch../gradlew WordPress:detekt
and verify that the build is successful.config/detekt/baseline.xml
file, comment out theDetekt's
baseline configuration within theWordPress/build.gradle
file and run./gradlew WordPress:detekt
again. Verify that the build fails, reporting880
issues.detekt
IDE plugin and configure it following the instructions within thecoding-style.md
readme file. Verify that everything works and that the IDE reportsDetekt
violations as well.Detekt
relatedCircle CI
job and verify correctness.Questions (❓):
Detekt
was configured on the rootbuild.gradle
file, within theallprojects { ... }
scope. However, I have noticed that thesubprojects { ... }
is utilised as well for static analysis tools likeKtLint
. Do I need to add an additionaltask
forDetekt
within thesubprojects { ... }
?build.gradle
file, calledviolationCommentsToGitHub
. This task has aviolations
configuration forCheckStyle
. Do I need to add something similar forDetekt
?Merge Instructions (⚠️ ):
Not Ready for Merge
label.PR submission checklist:
RELEASE-NOTES.txt
if necessary.