Would a middle-ground be to add a warning-count check to the pull-request pipeline, which would then be reflected to the GitHub PR?
On Tue, Jan 15, 2019 at 2:09 PM Udo Kohlmeyer <u...@apache.org> wrote: > So, to reduce the number of new warnings, are we then going to > standardize on JDK versions? i.e, we only build with JDK 8 build 192 and > JDK11 build 03, because changes in JDK can introduce warnings. > > I'm all for reducing warnings, but they are warnings. Don't think we > need to error, or break on them. > > -1 for break build on warnings. > > --Udo > > On 1/15/19 13:28, Dan Smith wrote: > > Sounds good. +1 to failing the build if new warnings are introduced. > > > > -Dan > > > > On Tue, Jan 15, 2019 at 12:59 PM Galen O'Sullivan <gosulli...@pivotal.io > > > > wrote: > > > >> I'm for failing CI on warnings. It would be nice to reduce or eliminate > our > >> existing build warnings as well. > >> > >> Thanks, > >> Galen > >> > >> > >> On Tue, Jan 15, 2019 at 12:33 PM Peter Tran <pt...@pivotal.io> wrote: > >> > >>> Hello! > >>> > >>> I've noticed that there is no mechanism in which we prevent new PRs > from > >>> introduce new build warnings. In our PR template we ask people to self > >>> report that they have a "clean build" but nothing more to ensure we're > >> not > >>> adding new warnings. > >>> > >>> Has there been an initiative to address this in the past? Would it be > too > >>> restrictive if CI fails if new warnings are introduced in a PR? > >>> > >>> Thanks > >>> -- > >>> Peter Tran > >>> >
