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 wrote:
> So, to reduce the number of new warnings, are we then going to
> standardize on JDK versions? i.e, we only bu
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
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
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 1
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 wrote:
> Hello!
>
> I've noticed that there is no mechanism in which we prevent new PRs from
> introduce new build warnings. In
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 th
