I don't have any experience of using SonarQube but Coverity worked well for me. Looks like it already has beam repo: https://scan.coverity.com/projects/11881
On Thu, Jan 3, 2019 at 1:27 PM Reuven Lax <re...@google.com> wrote: > 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 >> >