Re: Is --fail-at-end buggy?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Is --fail-at-end buggy?

Tibor Digana
So we are on the same way. Shortly speaking both options should build
modules in the same way but the exit code should be a difference.
This is problem in my company: We want to execute all unit tests of all
modules but the compiler should not complain since the classes are pretty
consistent and can be compiled. We want to get entire picture of all unit
tests and Exit Code should be 1 due to the tests fail.

On Fri, Feb 2, 2018 at 9:21 AM, Robert Scholte <[hidden email]> wrote:

> I have the same expectations as Arnaud
>
> On Thu, 01 Feb 2018 13:55:20 +0100, Arnaud Héritier <[hidden email]>
> wrote:
>
> yes I think I agree
>> my expectation would be
>>
>>  -fae,--fail-at-end                     Only fail the build afterwards;
>> allow all non-impacted builds to continue
>>
>> 0 if no problem, 1 if any module failed
>>
>>  -ff,--fail-fast                        Stop at first failure in
>> reactorized builds
>>
>> 0 if no problem, 1 if failed
>>
>>  -fn,--fail-never                       NEVER fail the build, regardless
>> of
>> project result
>>
>> Always 0
>>
>>
>> On Thu, Feb 1, 2018 at 1:06 PM, Tibor Digana <[hidden email]>
>> wrote:
>>
>> I think this is bug (mvn --fail-at-end) because intermediate modules are
>>> skipped. Unlike --fail-never runs all modules but returns exit 0. I want
>>> exit 1 with --fail-at-end .
>>>
>>> WDYT?
>>>
>>> Cheers
>>> Tibor
>>>
>>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Is --fail-at-end buggy?

stephenconnolly
On Sun 4 Feb 2018 at 18:35, Tibor Digana <[hidden email]> wrote:

> So we are on the same way. Shortly speaking both options should build
> modules in the same way but the exit code should be a difference.
> This is problem in my company: We want to execute all unit tests of all
> modules but the compiler should not complain since the classes are pretty
> consistent and can be compiled. We want to get entire picture of all unit
> tests and Exit Code should be 1 due to the tests fail.


So to my mind, fail-never is something different.

With fail-never all the mojo executions are attempted, so *in theory*
downstream modules may still be able to build.

With fail-at-end, a module fails but we do not stop independent modules
from success.

What we want is a halfway house, where we continue executing phases after
the failed goal and then fail at the end if any phase failed at all

>
>
> On Fri, Feb 2, 2018 at 9:21 AM, Robert Scholte <[hidden email]>
> wrote:
>
> > I have the same expectations as Arnaud
> >
> > On Thu, 01 Feb 2018 13:55:20 +0100, Arnaud Héritier <[hidden email]
> >
> > wrote:
> >
> > yes I think I agree
> >> my expectation would be
> >>
> >>  -fae,--fail-at-end                     Only fail the build afterwards;
> >> allow all non-impacted builds to continue
> >>
> >> 0 if no problem, 1 if any module failed
> >>
> >>  -ff,--fail-fast                        Stop at first failure in
> >> reactorized builds
> >>
> >> 0 if no problem, 1 if failed
> >>
> >>  -fn,--fail-never                       NEVER fail the build, regardless
> >> of
> >> project result
> >>
> >> Always 0
> >>
> >>
> >> On Thu, Feb 1, 2018 at 1:06 PM, Tibor Digana <[hidden email]>
> >> wrote:
> >>
> >> I think this is bug (mvn --fail-at-end) because intermediate modules are
> >>> skipped. Unlike --fail-never runs all modules but returns exit 0. I
> want
> >>> exit 1 with --fail-at-end .
> >>>
> >>> WDYT?
> >>>
> >>> Cheers
> >>> Tibor
> >>>
> >>>
> >>
> >>
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
--
Sent from my phone