document the various code quality tools in our Developer FAQ#1038
document the various code quality tools in our Developer FAQ#1038epugh merged 4 commits intoapache:mainfrom
Conversation
dev-docs/FAQ.adoc
Outdated
| We also check for security vulnerable components in Solr using the | ||
| [OWASP](https://plugins.gradle.org/plugin/org.owasp.dependencycheck) Gradle plugin, as part of the | ||
| `check` task. |
There was a problem hiding this comment.
OWASP doesn't run by default. ./gradlew check -x test -Dvalidation.owasp=true with the parameter is needed.
There was a problem hiding this comment.
Can also be run independently with ./gradlew owasp.
There was a plan to run OWASP checks in Jenkins, but I cannot find it.
|
Do we think it's useful to add the RAT and other validations??? Or are we going beyond FAQ... I was on the fence about OWASP... |
dsmiley
left a comment
dsmiley
left a comment
There was a problem hiding this comment.
Thanks for doing this!
I think we should add Sonatype Lift to this list.
Link: https://lift.sonatype.com/
Lift is an automated code reviewer. As with human reviewers, it's a good practice to respond to each comment to reflect on the recommendation. Of course, automated code analysis will turn up false-positives. Tip: There is no point in responding to Lift with the
ignorecommand because we don't gate PRs on Lift.
dev-docs/FAQ.adoc
Outdated
|
|
||
| === How do we ensure coding standards and quality? | ||
|
|
||
| We use a number of tools for ensuring that Solr's codebase follows our community standards. The most |
There was a problem hiding this comment.
nit: when writing adoc files, consider one sentence per line. It helps with diffs.
There was a problem hiding this comment.
So, I guess we don't have a "we want 80 charaters more or less per line"? We don't have lint on that today... I'll make the change.
There was a problem hiding this comment.
This isn't mandatory but is good-practice. Cassandra did lots of such changes over the ref guide, and I'm grateful for it.
dev-docs/FAQ.adoc
Outdated
| [Error Prone](https://errorprone.info/) goes beyond static type checking and recommends fixes | ||
| for common bug patterns. Error Prone is normally run during a CI build, to run it locally via: | ||
|
|
||
| `./gradlew check -Pvalidation.errorprone=true` |
There was a problem hiding this comment.
that will also run tests; right? instead run the specific task if that's what we're trying to show someone.
There was a problem hiding this comment.
In your latest commit, you improved this to exclude tests so it's "good enough" but nonetheless, it'd be nice to show someone how to directly run this specific validation (as we do above for OWASP) rather than an entire build phase (check) and exclude various things.
There was a problem hiding this comment.
I tried to find a actual "gradle target" (I think the word is) and didn't have any luck. I think it's welded directly into the check behavior...
There was a problem hiding this comment.
I turned up nothing as well; seems hooked into the compiler.
There was a problem hiding this comment.
So I am going to pretend to be @gerlowskija and say "Teperating this into it's own target is probably a seperate PR"...
So, do you think this is ready to commit?
There was a problem hiding this comment.
Absolutely; I approved 6 hours ago.
Thanks!
|
|
4 participants
https://issues.apache.org/jira/browse/SOLR-XXXXX
Description
there has been some great work around code quality recently, and I realized that I don't really know what all the tools are that are available... So what is a new person going to do?
Solution
Add an entry to the developer docs FAQ.