Skip to content
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

Merged
merged 17 commits into from
Feb 12, 2021
Merged

Detekt Integration - Phase.1 #13996

merged 17 commits into from
Feb 12, 2021

Conversation

ParaskP7
Copy link
Contributor

@ParaskP7 ParaskP7 commented Feb 8, 2021

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 the WordPress 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 (🧪 ):

  • Make sure to read the external and internal links mention above to get an overall idea on what Detekt has to offer, how it can be configured and utilised.
  • Pull detekt-integration on a local branch.
  • Run ./gradlew WordPress:detekt and verify that the build is successful.
  • Delete the config/detekt/baseline.xml file, comment out the Detekt's baseline configuration within the WordPress/build.gradle file and run ./gradlew WordPress:detekt again. Verify that the build fails, reporting 880 issues.
  • Install the detekt IDE plugin and configure it following the instructions within the coding-style.md readme file. Verify that everything works and that the IDE reports Detekt violations as well.
  • Locate the Detekt related Circle CI job and verify correctness.

Questions (❓):

  • For @loremattei: 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 { ... }?
  • For @loremattei: 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?

Merge Instructions (⚠️):

  1. Make sure 2 reviewers have approved the PR (@loremattei and @malinajirka).
  2. Remove the Not Ready for Merge label.
  3. Merge this PR.

PR submission checklist:

  • I have considered adding unit tests where possible.
  • I have considered adding accessibility improvements for my changes.
  • I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

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.
@peril-wordpress-mobile
Copy link

peril-wordpress-mobile bot commented Feb 8, 2021

You can trigger optional UI/connected tests for these changes by visiting CircleCI here.

@ParaskP7 ParaskP7 changed the title Detekt integration Detekt Integration Feb 8, 2021
@peril-wordpress-mobile
Copy link

peril-wordpress-mobile bot commented Feb 8, 2021

You can test the changes on this Pull Request by downloading the APK here.

Copy link
Contributor

@malinajirka malinajirka left a 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?

build.gradle Show resolved Hide resolved
parallel = false
debug = false
reports {
html.enabled = true
Copy link
Contributor

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.

Copy link
Contributor Author

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:

  1. The output files are very small anyway, thus there will not be a build overhead,
  2. 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

Copy link
Contributor

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. 👍

Copy link
Contributor Author

@ParaskP7 ParaskP7 Feb 10, 2021

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.

Copy link
Contributor

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.

config/detekt/detekt.yml Show resolved Hide resolved
config/detekt/detekt.yml Outdated Show resolved Hide resolved
config/detekt/detekt.yml Outdated Show resolved Hide resolved
config/detekt/detekt.yml Show resolved Hide resolved
config/detekt/detekt.yml Show resolved Hide resolved
config/detekt/detekt.yml Outdated Show resolved Hide resolved
config/detekt/detekt.yml Show resolved Hide resolved
config/detekt/detekt.yml Show resolved Hide resolved
@ParaskP7
Copy link
Contributor Author

ParaskP7 commented Feb 9, 2021

👋 @malinajirka !

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.

Thank you so much for this thorough review and all the comments you left Jirka, much much appreciated! 💪

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?

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.

@ParaskP7 ParaskP7 changed the title Detekt Integration Detekt Integration - Phase.1 Feb 9, 2021
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.
Two new issues were added to the baseline.
@ParaskP7 ParaskP7 requested a review from malinajirka February 9, 2021 13:33
@ParaskP7
Copy link
Contributor Author

ParaskP7 commented Feb 9, 2021

👋 @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! 🙏

Copy link
Contributor

@malinajirka malinajirka left a 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 ;).

Copy link
Contributor

@loremattei loremattei left a 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.

@ParaskP7
Copy link
Contributor Author

👋 @loremattei !

I tested following the steps you provided and it worked as expected, other than what @malinajirka already noted.

Thank you so much for the review! 🙏 Yeap, @malinajirka was really thorough! ❤️

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.

Thanks for double checking on that, I agree! 🙏

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.

Coolio, let me check on that as well before merging that to develop. Or, question (❓), do you think we can merge it even without this violations configuration and add that one as a separate task afterwards?

@ParaskP7
Copy link
Contributor Author

ParaskP7 commented Feb 10, 2021

👋 @loremattei !

Coolio, let me check on that as well before merging that to develop.

I checked the tool (violation-comments-to-github-gradle-plugin) and maybe the below configuration is what we need to have violation comments work for both Checkstyle and Detekt now. Wdyt?

image

I'll try to push a commit with that configuration with both, some CheckStyle and/or Detekt issues, to see this violation comments setup work as expected.

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'.
@ParaskP7
Copy link
Contributor Author

ParaskP7 commented Feb 11, 2021

👋 @loremattei !

I have been trying to update the violations configuration while having some issues with Detekt (7 of them), but I am not seeing any output. I am not familiar with this tool and how it outputs the violations. Can you maybe help with that?

PS: I am now going to create a separate test branch with a CheckStyle violation, then open a test PR and observe the output (if any). Will keep you posted. #14033
PSS: I also checked Circle CI and the Violations job and saw this below, maybe something is wrong, I am not sure:

#!/bin/bash -eo pipefail
if [ -n "$GITHUB_API_TOKEN" ]; then
  ./gradlew --stacktrace violationCommentsToGitHub -DGITHUB_PULLREQUESTID=${CIRCLE_PULL_REQUEST##*/} -DGITHUB_OAUTH2TOKEN=$GITHUB_API_TOKEN
else
  echo "Not posting lint errors to Github because \$GITHUB_API_TOKEN is not found"
fi

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants