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/ 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
