maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: [IMPORTANT] Re: Git migration next steps
Date Tue, 02 Jan 2018 12:16:37 GMT
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 <tibordigana@apache.org> wrote:

> No issue. Infra solved the last problem I have mentioned.
>
> On Mon, Jan 1, 2018 at 2:53 PM, Tibor Digana <tibordigana@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 <khmarbaise@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-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message