[petsc-dev] testing with Pipelines before making merge request

[Satish Balay]

Well I think there should be no e-mail when a MR is created - if folk are not added to the MR.

However some MRs go back into development mode [after initial reviews] - thus triggering many e-mails to the participants. So one would have to manually toggle their 'notification' setting on the MR to avoid the e-mail [and perhaps re-enable this - when its ready for re-review?]

Satish

On Tue, 23 Jun 2020, Scott Kruger wrote:

> 
> 
> I see the value in this, but am somewhat ambivalent..
> 
> As a workflow, I did do the "Assign to me" and then when it was actually ready
> to merge, I changed the status to "Ready to merge" and assigned to Satish.  I
> liked this because the gitlab MR button in the upper right shows the ones
> assigned to you by default -- it's a nice To Do list.
> 
> Of course, with your petscgitbash, effectively you can see your MR To Do list
> from the command-line, and having a tidy MR list for PETSc itself is really
> nice.  I agree that PETSc's is a bit messy.
> 
> However, if I'm going to get a conflict, it's almost certainly going to be
> from Junchao and I like seeing his MR's just so I know which files he's
> working on.  (Click that MR button, clear the search with your name, change
> Author=@jczhang07, and it'll appear in your recent searches so easy-peasy).
> Yes, I can do a
>     git branch -a | grep jczhang
> but there are a lot of branches there, and there isn't as much explanation as
> you get with an MR.
> 
> Of course, I could try actually emailing or *gasp* talking to Junchao, but
> isn't the whole point of the internet to minimize contact with people?  ;-)
> 
> And yes, I can see it when the MR is ready, but one (admittedly generally
> positive) side-effect is going to be a shorter MR cycle.
> 
> Scott
> 
> P.S.  I await the perfect git command(s) that renders my whole argument moot
> and makes me feel like a git noob.
> 
> 
> 
> On 6/23/20 6:21 PM, Barry Smith wrote:
> > 
> >    One can test a branch with Pipelines (and fix it) before making a merge
> >    request. GitLab is smart enough to remember that branch has passed the
> >    pipeline and not require another test just because you make a MR (unless
> >    of course you change something based on MR feedback).
> > 
> >    This can prevent some churn in merge request messages and constant
> >    pushes. Of course if one needs help in fixing a pipeline problem one is
> >    free to make a WIP merge request and ask for help there.
> > 
> >     Barry
> > 
> 
>