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