Question about Gitlab MR workflow.

Simon Peyton Jones simonpj at microsoft.com
Thu May 9 08:02:43 UTC 2019


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


More information about the ghc-devs mailing list