tried to analyze maven-javadoc-plugin current failure: https://builds.apache.org/job/maven-box/job/maven-javadoc-plugin/job/master/
looking at logs from the stage view gives manageable log for each OS/jdk build. But I see 2 issues: 1. everything is marked as having test issues, when only Windows builds have such a failing issue (on detectLinks IT): this does not seem to be related to fail fast configuration from the first build 2. once I know that I need to investigate detectLinks IT on Windows builds (each JDK: 7, 8 or 9), how can I get workspace content for each build? Usually, I used workspace view to get build.log and try to understand what the failure was, but nowadays, I can't or I don't know how to do... This is here on a failure that I suppose is relevant: I suppose some of the failing jobs currently are more false positives, then harder to analyze... but let's start with normal debugging of a normal issue detected by the CI given its wide OS*jdk coverage 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
