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
