tamaya-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William Lieurance <william.lieura...@namikoda.com>
Subject Re: Question - should Sonar fail our builds?
Date Thu, 02 May 2019 08:10:43 GMT
Hi all,

A thing I just discovered about the sonar integration we've got: if you open a pull request
from a forked repo instead of a branch in the shared apache/incubator-tamaya* repo, sonarcube
won't run and will, at this point, fail the build.  That means that only folks who have access
to create branches in the shared repo (namely, the committers to this project) can ever get
a pull request with a passing test.  I'm very much in favor of enforcing the things that sonar
is enforcing, but I don't think we can afford to create that kind of hurdle to the community
at large.  I'll vote against letting sonar fail the build until we can get past this issue.

The doc that finally told me what I was doing wrong: https://docs.travis-ci.com/user/sonarcloud/#analysis-of-internal-pull-requests

From: Aaron Coburn <aaron.coburn@gmail.com>
Sent: Wednesday, May 1, 2019 5:45 PM
To: dev@tamaya.incubator.apache.org
Subject: Re: Question - should Sonar fail our builds?

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


On Wed, May 1, 2019 at 4:57 PM P. Ottlinger <pottlinger@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?
> Cheers,
> Phil

View raw message