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