+1 to enabling warnings first. This will allow us to evaluate how much value we get and the frequency of false-positives / noise.
I'd be curious to hear from those that've worked in other projects on experiences with SonarQube or other tools. At Google, code coverage is integrated into the code review workflow, which is very valuable for spotting testing gaps during review. Some details here: https://testing.googleblog.com/2014/07/measuring-coverage-at-google.html On Thu, Jan 3, 2019 at 11:34 AM Robert Burke <rob...@frantil.com> wrote: > I had the same question, and tt supports many more than we do: > https://www.sonarqube.org/features/multi-languages/ > > All the various rules checks have clear explanations and justifications > for why they're doing what they do. > It would be quite handy as part of the precommits I think, if at least as > a warning or similar, until we get the noise down. > > On Thu, 3 Jan 2019 at 10:55, Udi Meiri <eh...@google.com> wrote: > >> +1 for adding more code quality signals. Could we add them in an >> advisory-only mode at first? (a warning and not an error) >> >> I'm curious how the "technical debt" metric is determined. >> >> I'm not familiar with SonarQube. What languages does it support? >> >> On Thu, Jan 3, 2019 at 10:19 AM 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 >>> >> -- Got feedback? tinyurl.com/swegner-feedback
