You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Tibor Digana <ti...@apache.org> on 2018/01/01 13:53:56 UTC
Re: [IMPORTANT] Re: Git migration next steps
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 <kh...@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
>
>
Re: [IMPORTANT] Re: Git migration next steps
Posted by Stephen Connolly <st...@gmail.com>.
https://issues.apache.org/jira/browse/MJAVADOC-510
On 2 January 2018 at 13:42, Robert Scholte <rf...@apache.org> wrote:
> On Tue, 02 Jan 2018 13:16:37 +0100, Stephen Connolly <
> stephen.alan.connolly@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 <ti...@apache.org> wrote:
>>
>> No issue. Infra solved the last problem I have mentioned.
>>>
>>> On Mon, Jan 1, 2018 at 2:53 PM, Tibor Digana <ti...@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
>>> >>
>>> >>
>>> >
>>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [IMPORTANT] Re: Git migration next steps
Posted by Robert Scholte <rf...@apache.org>.
On Tue, 02 Jan 2018 13:16:37 +0100, Stephen Connolly
<st...@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 <ti...@apache.org> wrote:
>
>> No issue. Infra solved the last problem I have mentioned.
>>
>> On Mon, Jan 1, 2018 at 2:53 PM, Tibor Digana <ti...@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
>> <kh...@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
>> >>
>> >>
>> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [IMPORTANT] Re: Git migration next steps
Posted by Stephen Connolly <st...@gmail.com>.
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 <ti...@apache.org> wrote:
> No issue. Infra solved the last problem I have mentioned.
>
> On Mon, Jan 1, 2018 at 2:53 PM, Tibor Digana <ti...@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 <kh...@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
> >>
> >>
> >
>
Re: [IMPORTANT] Re: Git migration next steps
Posted by Tibor Digana <ti...@apache.org>.
No issue. Infra solved the last problem I have mentioned.
On Mon, Jan 1, 2018 at 2:53 PM, Tibor Digana <ti...@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 <kh...@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
>>
>>
>