Hi,
On 31/12/17 12:44, Hervé BOUTEMY wrote:
another interesting case:
https://builds.apache.org/job/maven-box/job/maven-shared-utils/job/master/
when you look at each step logs from the stage view, you see no issue
but the build is marked as failed
and if you look at the unit tests marked as failed:
https://builds.apache.org/job/maven-box/job/maven-shared-utils/job/master/
lastCompletedBuild/testReport/
The failures on the tests here are based on the issue with the "@" in
the directory name (See
https://issues.apache.org/jira/browse/SUREFIRE-1312)..
Upgrading to surefire 2.20.1 will solve that problem..(Based on the
current state of my experience)...
See
https://builds.apache.org/job/maven-box/job/maven-shared-utils/job/master/4/
Kind regards
Karl Heinz
you don't know on which build (OS*JDK) the failures happen
IMHO, in parallel to the javadoc IT failure investigation, this maven-shared-
utils gives us another interesting case to fix
Regards,
Hervé
Le dimanche 31 décembre 2017, 11:49:59 CET Hervé BOUTEMY a écrit :
Le dimanche 31 décembre 2017, 11:05:39 CET Stephen Connolly a écrit :
[...]
what are all the open tasks links?
was supposed to be fixed after Jenkins plugin upgrade this week
@Stephen is this a known issue?
I may have to tweak the shared lib also. It will be Tuesday before I turn
on my Mac
perfect: have nice holidays, working on it next year is perfect :)
[...]
Honestly the current jenkins result is complicated to use....
when the reseult is a passing build, it's perfect, but I confirm that
when
there is a failure, it's a pain to understand where is the failure
(which
OS/
jdk, which test)
and eventually detect if there are false positives on some conditions...
So there are two issues imho:
1. Fast fail kills other parallel executions in such a way that they
report
as failed. I’d like them to flag as aborted instead. That would make
identification from the stage view or blue ocean easier.
yes, this would be a good first enhancement
2. The parallel logs. This is a pipeline design decision. You are better
off viewing logs through stage view or blue ocean.
last time I tried, I did not find output clear: but perhaps it was on
aborted builds marked as failed... I'll have to try with that issue in
mind.
And as far I can see SNAPSHOT are not anymore deployed whereas they
were
deployed previously.
IMHO it's very convenient as some users test our fixes....
@Stephen adding auto-deploy for master branch could make sense, isn't
it?
I really think auto-deploy of snapshots is an anti-pattern. If we want it
to be for CI only in a CI dedicated repo, I can find that acceptable...
but
otherwise I really hate the idea.
I don't understand: a SNAPSHOT-dedicated repository is like a mini
continuous deployment. We have a SNAPSHOT-dedicated repository exactly for
that, configured as repositories and distributionManagement in Apache
Parent POM http://maven.apache.org/pom/asf/
I understand there are issues if we auto-deploy from branches, since we have
no version scheme to make a difference in the SNAPSHOT repo for every
branch: that's why I restrict the auto-deployment to master.
But it's the first time I hear about issues with a SNAPSHOT repo to make
SNAPSHOTs public (as SNAPSHOTs, ie advertized as latest & non-reproducible,
to test early): the only issues I understood was about people wanting to
make these reproducible, then avoid SNAPSHOT and call it "continuous
delivery" (which IMHO adds a lot of unused releases that you can't delete
if you don't master precisely who your consumers are: then in such open
situation, you get a bloated repo...)
Regards,
Hervé
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
