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
> >
> >
>
