Question about Gitlab MR workflow.

Iavor Diatchki iavor.diatchki at
Wed May 8 23:19:03 UTC 2019


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 :

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

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!


More information about the ghc-devs mailing list