So yes, using -Dmaven.test.failure.ignore=true changes the exit code from 1
to 0. So if your linking commands you might not spot a previous command
actually silently errored.
As I want jenkins to fail at that step, and not progress to subsequent
steps. Not point wasting computing resources once all compile issues are
know and all tests issues for tests that could be execute are known.
I could probably configure another plugin to parse the output and detect
that no tests have failed, but decided not to investigate that.
John
On Sat, 26 Feb 2022 at 11:41, Falko Modler <f.mod...@gmx.net> wrote:
> John, is there a reason why you don't use
> -Dmaven.test.failure.ignore=true? This has been my Jenkins setup for
> years and with that I don't need two mvn runs.
>
> Apart from that I can relate to Alexander's use case in that locally you
> simply don't have those Jenkins reporting tools, telling you which tests
> failed overall.
> This can be rather annoying, especially when building in parallel, as
> test result will be all over the place.
>
> I'm not convinced though that this should be a general mvn flag.
> Ideally, surefire chould provide something for that (e.g. an extension).
> Next best thing is a separate extension, which I think was discussed
> here before.
>
> Cheers,
>
> Falko
>
> Am 26.02.2022 um 12:18 schrieb John Patrick:
> > So I understand the option, but for the average developer understanding
> the
> > intermixed output might be a nightmare. If someone is building the code
> > they can just do -SkipTests and -fae, fix those, then go back to run the
> > tests.
> >
> > I do a similar setup on Jenkins, with this kind of Jenkinsfile structure;
> >
> > try {
> > withEnv(...)
> > configFileProvider(...)
> > try {
> > ./mvnw clean install -DskipTests -fae
> > } finally {
> > ./mvnw verify -fae
> > }
> > }
> > }
> > } finally {
> > recordIssues enabledForFailure: true, tools: [mavenConsole()]
> > recordIssues aggregatingResults: true, enabledForFailure: true, tools:
> > [java(pattern: '**/src/main/java/**')]
> > recordIssues aggregatingResults: true, enabledForFailure: true, tools:
> > [junitParser(pattern:
> > '**/target/failsafe-reports/*.xml,**/target/surefire-reports/*.xml')]
> > publishCoverage adapters:
> > [jacocoAdapter('**/target/site/jacoco/jacoco.xml')]
> > }
> >
> > - Every compile error is captured assuming it's dependencies compile
> > - Every test is execute where the module builds
> > - Report issues and coverage for everything that executed
> >
> > John
> >
> >
> > On Sat, 26 Feb 2022 at 10:37, Delany <delany.middle...@gmail.com> wrote:
> >
> >> I understand your use case Alex, just not your process. As this is the
> >> users list Im not about to solve the issue of a missing
> --fail-all-at-end
> >> switch, but I could try to think of workarounds.
> >> Delany
> >>
> >>
> >> On Sat, 26 Feb 2022 at 09:32, Alexander Kriegisch <
> >> alexan...@kriegisch.name>
> >> wrote:
> >>
> >>> Delany,
> >>>
> >>> you are completely misunderstanding my use case. I am building with
> >>> every push, that is the pain, because I have a choice to
> >>>
> >>> -- either see all test results with '-fn' but get a wrong build
> result
> >>> (passed)
> >>>
> >>> -- or fewer test results with '-fae' and a correct build result
> >>> (failed).
> >>>
> >>> I do *not* wish to run tests in a later phase. I have no idea where you
> >>> got that idea from. I simply want the build to continue for modules
> >>> dependent on ones with failing tests, so I can find out if they build
> >>> successfully and whether or not they also have failing tests. Then in
> >>> the end, after all modules have been built and all tests run (for those
> >>> modules which could actually be built without compile errors, of
> >>> course), I want to see an overall test result and a properly failed
> >>> build. In plain English: I want what '-fae' always should have done to
> >>> begin with. I really don't know what is so difficult to understand
> about
> >>> this simple requirement: build as much as possible, test as much as
> >>> possible, then report the correct result at the end. I want failed
> tests
> >>> to fail the build in the end, but I do not want them to keep dependent
> >>> modules from being built and tested.
> >>>
> >>> --
> >>> Alexander Kriegisch
> >>> https://scrum-master.de
> >>>
> >>>
> >>> Delany schrieb am 26.02.2022 14:17 (GMT +07:00):
> >>>
> >>>> Oh its not, im just being thorough.
> >>>> It just seems like your build iteration isn't frequent enough. If
> >> you're
> >>>> not building on every MR/PR or with every push, maybe you need a
> >> separate
> >>>> test build. Or maybe your reactor is too large and you need to split
> it
> >>>> into separate projects. You could also leave the reactor but build via
> >> a
> >>>> script that looks for pom files and tests them one at a time. Ugly,
> but
> >>>> effective.
> >>>> Bottom line is that install and deploy phases don't create
> dependencies
> >>>> within a reactor, so its no biggy that they delay their execution
> until
> >>>> after. Anything that happens before then does, and its not
> unreasonable
> >>> to
> >>>> expect development to work within that constraint.
> >>>> Delany
> >>>>
> >>>>
> >>>> On Fri, 25 Feb 2022 at 19:40, Alexander Kriegisch <
> >>> alexan...@kriegisch.name>
> >>>> wrote:
> >>>>
> >>>>> Thanks for digging, Delany. However, I am failing to see how this is
> >>>>> meant to solve my problem. Could you elaborate, please?
> >>>>> --
> >>>>> Alexander Kriegisch
> >>>>> https://scrum-master.de
> >>>>>
> >>>>>
> >>>>> Delany schrieb am 25.02.2022 18:05 (GMT +07:00):
> >>>>>
> >>>>>> Alexander, here it is: https://github.com/raydac/mvn-finisher
> >>>>>> Delany
> >>>>>>
> >>>>>> On Mon, 7 Feb 2022 at 08:17, Delany <delany.middle...@gmail.com>
> >>> wrote:
> >>>>>>> Someone already wrote an "at end maven plugin". I used it for a
> >> while
> >>>>> but
> >>>>>>> removed it. Can't for the life of me find it in
> >>>>>>> github/google/confluence/git log. Sorry!
> >>>>>>> Delany
> >>>>>>>
> >>>>>>>
> >>>>>>> On Mon, 7 Feb 2022 at 04:38, Alexander Kriegisch <
> >>>>> alexan...@kriegisch.name>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>>>> In case you are ready to make you own plugin, it is relatively
> >>> easy.
> >>>>>>>> I am not, Lasse. I also want this to work on the command line and
> >>> not
> >>>>>>>> depend on CI-system-specific workarounds. But thank you for your
> >>>>>>>> insightful ideas, I really appreciate them.
> >>>>>>>>
> >>>>>>>> Tibor, actually I wanted to avoid a potentially lengthy debate on
> >>> basic
> >>>>>>>> principles, but I agree on having one, if you feel it is
> >> necessary.
> >>> I
> >>>>>>>> owe you that much, because it tells me that you are not taking
> >>> design
> >>>>>>>> decisions lightly. So if I can contribute to your decision-making
> >>>>>>>> process, I shall humbly do so. Not being a Maven (plugin)
> >> developer
> >>>>>>>> myself, but rather a just user with a bit of background knowledge,
> >>> I in
> >>>>>>>> fact did previously in this thread comment on the two famous
> >>> '*AtEnd'
> >>>>>>>> precedence cases already:
> >>>>>>>>
> >>>>>>>>>>>> Install and Deploy plugins (...): 'installAtEnd' and
> >>> 'deployAtEnd'
> >>>>>>>>>>>> are blessings IMO, and they are cornerstones of my work,
> >>> because
> >>>>>>>>>>>> they help to avoid half-installed and - even worse -
> >>> half-deployed
> >>>>>>>>>>>> multi-module projects which would lead to inconsistencies in
> >>>>>>>>>>>> repositories and might be hard to rectify in remote
> >>> repositories,
> >>>>>>>>>>>> "burning" release numbers unnecessarily.
> >>>>>>>> The gist is: Those '*AtEnd' features have user value. If you say
> >>> that
> >>>>>>>> they might be difficult to maintain and shield against side
> >>> effects, I
> >>>>>>>> have to take your word for it. So we have a trade-off situation
> >>> here,
> >>>>>>>> chances vs risks. As the person requesting such a feature, of
> >>> course I
> >>>>>>>> have a chances bias. As a plugin maintainer, of course you take a
> >>> more
> >>>>>>>> conservative or defensive stance. I understand that. In the end,
> >> it
> >>> is
> >>>>>>>> your decision. Hopefully others here can contribute more
> >>> substantially
> >>>>>>>> to the discussion than I can.
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Alexander Kriegisch
> >>>>>>>> https://scrum-master.de
> >>>>>>>>
> >>>>>>>>
> >>> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >>>>>>>> For additional commands, e-mail: users-h...@maven.apache.org
> >>>>>>>>
> >>>>>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >>>>> For additional commands, e-mail: users-h...@maven.apache.org
> >>>>>
> >>>>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >>> For additional commands, e-mail: users-h...@maven.apache.org
> >>>
> >>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
