I find Sonar to be useful, but I also take those analyses with a significant grain of salt.
First of all, whether a given commit will pass or fail the sonar analysis is a bit of a moving target, and it's also not easy to reproducible locally. This means there is a bit of guesswork involved if getting a passing grade with Sonar is a requirement. In contrast, with checkstyle and other such tests, one can easily verify locally before pushing to master or creating a PR. Plus, with Sonar, it is sometimes the case that certain issues are really false positives, and having someone's pull request be rejected for that reason can be pretty uninviting, especially if the person is new to the code base or isn't familiar with how Sonar determines "failure". Aaron On Wed, May 1, 2019 at 4:57 PM P. Ottlinger <pottlin...@apache.org> wrote: > Hi, > > as of TAMAYA-277 I froze the current state as "gold standard" for future > builds. > > This yields problems due to refactorings that break the coding rules of > SonarCloud, example: > > https://github.com/apache/incubator-tamaya/pull/49/checks?check_run_id=116131187 > > Should we make the sonar quality checks optional or should they break > the builds? > > WDYT? > > Cheers, > Phil >
