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
>>
>>
>
