2017-11-10 11:35 GMT+01:00 Yasser Zamani <yasser.zam...@live.com>:
> 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-289265370Good idea, working on that :) Started with coveralls but other improvements are welcome :) https://github.com/apache/struts/pull/183 Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
