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?
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 <[email protected]> wrote: > No issue. Infra solved the last problem I have mentioned. > > On Mon, Jan 1, 2018 at 2:53 PM, Tibor Digana <[email protected]> > 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 <[email protected]> > > 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: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > >
