Question about Gitlab MR workflow.

[David Eichmann]

I've added a blurb in the wiki page about rebasing MRs:

GitLab usually complains that "Fast-forward merge is not possible" on 
your MR. If you see a green check and green "Rebase" button, NO action 
is necessary: your MR will be rebased automatically on merge. If instead 
you see an exclamation mark and disabled "Merge" button, you must rebase 
manually and fix any merge conflicts.

- David Eichmann

On 5/9/19 9:02 AM, Simon Peyton Jones via ghc-devs wrote:
> It would be good to add this advice to our "how-to-contribute" pages.
>
> Simon
>
> |  -----Original Message-----
> |  From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Ömer Sinan
> |  Agacan
> |  Sent: 09 May 2019 07:46
> |  To: Iavor Diatchki <iavor.diatchki at gmail.com>
> |  Cc: ghc-devs <ghc-devs at haskell.org>
> |  Subject: Re: Question about Gitlab MR workflow.
> |
> |  Hi,
> |
> |  >  About 4:  I really don't understand how this rebasing business is
> |  > intended to
> |  >  work: every time I rebase, I new CI job is fired up.  But,
> |  > presumably, while  this is going, other things are going to be merged
> |  with `master`, so I'd need
> |  >  to rebase again.   So, when would I ever stop rebasing?
> |
> |  Rebasing is actually not necessary. Marge adds your MR to the batch MR
> |  when it's approved and passed the tests. It doesn't have to be based on
> |  HEAD. So just don't bother with it.
> |
> |  Only time I needed a rebase was when there was a failing test in HEAD and
> |  a commit that disabled it had just landed. My MR was not passing the tests
> |  because of the test so I had to rebase.
> |
> |  Ömer
> |
> |  Iavor Diatchki <iavor.diatchki at gmail.com>, 9 May 2019 Per, 02:19 tarihinde
> |  şunu yazdı:
> |  >
> |  > Hello,
> |  >
> |  > I've just had a go at making a small MR on our new Gitlab system, and
> |  > I am a bit confused about the intended workflow.  I was following
> |  > these instructions :
> |  >
> |  > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
> |  > ab.haskell.org%2Fghc%2Fghc%2Fwikis%2Fworking-conventions%2Ffixing-bugs
> |  > &data=01%7C01%7Csimonpj%40microsoft.com%7C7261de3ecc064db43f9e08d6
> |  > d44a2702%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=UBBq5BHxuAdK
> |  > ZRSkl3wVCCNoVC23%2FF7cUETgUQcdx30%3D&reserved=0
> |  >
> |  > My question is about the steps after 2 (i.e., 3 and 4).  Step 5 about
> |  > the beer I already did :-)  Here was my experience so far:
> |  >
> |  > 1.  I made the changes I wanted yesterday over lunch: the change was
> |  > quite trivial, I added a NOINLINE pragma and some comments and I mage
> |  > the MR.
> |  >
> |  > 2. Sometime in the evening (half a day later!)  I got an e-mail from
> |  > the CI system that something had failed.  It was quite hard to tell
> |  > what had failed, and after poking around at the logs, it seemed like
> |  > it was some sort of spurious failures because things had timed out, I
> |  > think?
> |  >
> |  > 3. Today I got some feedback from a reviewer about some changes I
> |  > should make to the MR.  As I was working on those, I noticed that
> |  > every time I push to the MR, the CI is forking a new job.  I cancelled
> |  > some of those manually, to save on resources, as they already seem to
> |  > be taking half a day.
> |  >
> |  > 4. After making the changes, I noticed that Gitlab is asking me to
> |  > rebase my changes because, presumably, some other things have already
> |  > been merged.   It is easy enough to rebase my MR, but every time I do
> |  > so, this fires up a new CI job.   And, of course, this is going to
> |  > keep happening, until I am lucky enough to rebase just at the right
> |  > time?  This doesn't seem right.
> |  >
> |  > So my questions are specifically about step 3 and 4:
> |  >
> |  >    About 3:  wouldn't it make more sense to start firing up CI jobs
> |  > only after an MR has been approved for merging?
> |  >
> |  >    About 4:  I really don't understand how this rebasing business is
> |  > intended to work: every time I rebase, I new CI job is fired up.  But,
> |  > presumably, while this is going, other things are going to be merged
> |  > with `master`, so I'd need to rebase again.   So, when would I ever
> |  > stop rebasing?
> |  > Furthermore, in my case the rebase is trivial, but with a larger
> |  > patch, doing multiple rebases seems like a lot of wasted work.
> |  >
> |  > Any help would be appreciated!
> |  >
> |  > -Iavor
> |  > _______________________________________________
> |  > ghc-devs mailing list
> |  > ghc-devs at haskell.org
> |  > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.
> |  > haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=01%7C01
> |  > %7Csimonpj%40microsoft.com%7C7261de3ecc064db43f9e08d6d44a2702%7C72f988
> |  > bf86f141af91ab2d7cd011db47%7C1&sdata=wf4URw4jefgMCuXKtJMrTzTB4V2TJ
> |  > i%2F6%2F5uwfAdypps%3D&reserved=0
> |  _______________________________________________
> |  ghc-devs mailing list
> |  ghc-devs at haskell.org
> |  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
> |  ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
> |  devs&data=01%7C01%7Csimonpj%40microsoft.com%7C7261de3ecc064db43f9e08d6
> |  d44a2702%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=wf4URw4jefgMCuXK
> |  tJMrTzTB4V2TJi%2F6%2F5uwfAdypps%3D&reserved=0
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-- 
David Eichmann, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com

Registered in England & Wales, OC335890
118 Wymering Mansions, Wymering Road, London W9 2NF, England