https://issues.apache.org/jira/browse/MJAVADOC-510
On 2 January 2018 at 13:42, Robert Scholte <rfscho...@apache.org> wrote: > On Tue, 02 Jan 2018 13:16:37 +0100, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > Now here's a strange one.... The maven-javadoc-plugin is getting a lot of >> open tasks reported... because there are UNIT tests forking Maven... what >> is JavadocUtil.invokeMaven doing? Should it even be doing that... or >> should >> it be using a more correct helper from e.g. maven-invoker? >> > > Fully agree. Please make a JIRA ticket for it so we can investigate in > before the next release. > > > >> In any case we probably need to be >> injecting JENKINS_MAVEN_AGENT_DISABLED=true into the system environment >> of >> surefire... >> >> On 1 January 2018 at 14:53, Tibor Digana <tibordig...@apache.org> wrote: >> >> No issue. Infra solved the last problem I have mentioned. >>> >>> On Mon, Jan 1, 2018 at 2:53 PM, Tibor Digana <tibordig...@apache.org> >>> wrote: >>> >>> > What has changed that I am not authorized? I have updated ID to the >>> same >>> > password as before. >>> > I thought git-wip-us repository would be r/w. >>> > I still have this error: >>> > >>> > Counting objects: 68, done. >>> > Delta compression using up to 4 threads. >>> > Compressing objects: 100% (32/32), done. >>> > Writing objects: 100% (68/68), 9.25 KiB | 0 bytes/s, done. >>> > Total 68 (delta 14), reused 35 (delta 0) >>> > remote: You are not authorized to edit this repository. >>> > remote: >>> > To https://git-wip-us.apache.org/repos/asf/maven-surefire.git >>> > ! [remote rejected] SUREFIRE-1416 -> SUREFIRE-1416_2 (pre-receive >>> hook >>> > declined) >>> > error: failed to push some refs to 'https://git-wip-us.apache. >>> > org/repos/asf/maven-surefire.git' >>> > >>> > Cheers >>> > Tibor >>> > >>> > On Sun, Dec 31, 2017 at 1:28 PM, Karl Heinz Marbaise < >>> khmarba...@gmx.de> >>> > wrote: >>> > >>> >> Hi, >>> >> >>> >> On 31/12/17 12:44, Hervé BOUTEMY wrote: >>> >> >>> >>> another interesting case: >>> >>> https://builds.apache.org/job/maven-box/job/maven-shared-uti >>> >>> ls/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-uti >>> >>> ls/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-uti >>> >> ls/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 >>> >> >>> >> >>> > >>> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
