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