On 11/10/2017 12:58 PM, Lukasz Lenart wrote:
> I have added a Jenkins build to perform a Sonar analysis per push but
> I disabled spamming the dev@ list for now;-)
>
> https://builds.apache.org/analysis/overview?id=org.apache.struts%3Astruts2-parent
>
> 2017-11-08 11:18 GMT+01:00 Lukasz Lenart<[email protected]>:
>> There is a Sonar instance running
>> https://builds.apache.org/analysis/
Thanks! the Sonar instance seems has great analysis.
However, I thought about bring these to our maven build and github
system. I saw this approach a few month ago with Apache commons-lang.
When I requested a pull, I saw it fails because I don't add a @since tag
or because I don't use {} for a one line if statement! (they have
apache-rat:check clirr:check checkstyle:check in their maven build).
They also comment if the PR increase or decrease the current test
coverage [1].
I am thinking about if we can add nice checkers to our maven build and
git system little by little. The positive point is, at first place i.e.
the PR or the commit, we block making things worse by failing the build
if our quality metrics exceed some thresholds.
I know already there are a lot of Sonar issues but maybe we can ignore
current old ones and fail the build if new ones added at first place
i.e. a PR or commit :)
Isn't it better to resolve such issues at first place they occur? i.e.
forcing committer or pull requester to resolve them at place. Or maybe
you prefer to resolve newly added ones just before release in separate
commit(s)?
[1] https://github.com/apache/commons-lang/pull/261#issuecomment-289265370
