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