checkstyle and findbugs are already run as precommit checks, are they not? On Thu, Jan 3, 2019 at 7:19 PM Mikhail Gryzykhin <mig...@google.com> wrote:
> Hi everyone, > > In our current builds we (can) run multiple code quality checks tools like > checkstyle, findbugs, code test coverage via cubertura. However we do not > utilize many of those signals. > > I suggest to add requirements to code based on those tools. Specifically, > I suggest to add pre-commit checks that will require PRs to conform to some > quality checks. > > We can see good example of thresholds to add at Apache SonarQube provided > default quality gate config > <https://builds.apache.org/analysis/quality_gates/show/1>: > 80% tests coverage on new code, > 5% technical technical debt on new code, > No bugs/Vulnerabilities added. > > As another part of this proposal, I want to suggest the use of SonarQube > for tracking code statistics and as agent for enforcing code quality > thresholds. It is Apache provided tool that has integration with Jenkins or > Gradle via plugins. > > I believe some reporting to SonarQube was configured for mvn builds of > some of Beam sub-projects, but was lost during migration to gradle. > > I was looking for other options, but so far found only general configs to > gradle builds that will fail build if code coverage for project is too low. > Such approach will force us to backfill tests for all existing code that > can be tedious and demand learning of all legacy code that might not be > part of current work. > > I suggest to discuss and come to conclusion on two points in this tread: > 1. Do we want to add code quality checks to our pre-commit jobs and > require them to pass before PR is merged? > > Suggested: Add code quality checks listed above at first, adjust them as > we see fit in the future. > > 2. What tools do we want to utilize for analyzing code quality? > > Under discussion. Suggested: SonarQube, but will depend on functionality > level we want to achieve. > > > Regards, > --Mikhail >
