Question about Gitlab MR workflow.

[Ömer Sinan Ağacan]

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://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/fixing-bugs
>
> 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
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs