Re: [IMPORTANT] Re: Git migration next steps

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [IMPORTANT] Re: Git migration next steps

Hervé BOUTEMY
another interesting case:
https://builds.apache.org/job/maven-box/job/maven-shared-utils/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-utils/job/master/
lastCompletedBuild/testReport/

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: [hidden email]
> For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [IMPORTANT] Re: Git migration next steps

rfscholte
On Tue, 02 Jan 2018 13:16:37 +0100, Stephen Connolly  
<[hidden email]> 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 <[hidden email]> wrote:
>
>> No issue. Infra solved the last problem I have mentioned.
>>
>> On Mon, Jan 1, 2018 at 2:53 PM, Tibor Digana <[hidden email]>
>> 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  
>> <[hidden email]>
>> > 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: [hidden email]
>> >> For additional commands, e-mail: [hidden email]
>> >>
>> >>
>> >

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [IMPORTANT] Re: Git migration next steps

Hervé BOUTEMY
In reply to this post by Hervé BOUTEMY
Le mardi 2 janvier 2018, 14:32:00 CET Plamen Totev a écrit :

> Hi,
>
> > On Thu, Dec 28, 2017 at 10:43 AM, Hervé BOUTEMY <[hidden email]>
> > wrote: thank you Plamen: this script is really awesome!
>
> You're welcome. I'm glad it helped.
>
> > And I just pushed the result on maven-acr-plugin: you can see the result
> > live. As you can see, the tags on GitBox [2] are updated but not the tags
> > on GitHub [3] even if I tried to force to GitHub (and it looked ok)
> > I don't know if it's a major issue
>
> Would you check again. To me it looks like as if now the tags on
> GitHub are updated as well.
ok, perhaps I just misread GitHub, since it does not show the tag annotation
message, but only the message of the commit the tag points to

Then I just did a quit test on maven-antrun-plugin: GitBox tags were changed,
but GitHub tags were not. Then I pushed (-force) directly to GitHub (= what I
already did for GitBox), and I could see that this time the tags were changed.

Then I'll have to push the tags to GitHub explicitely, or there will be a
discrepency between GitBox and GitHub: I'll do it tonight

Regards,

Hervé

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]