Re: Obstacles for using GitLab CI

[Jonas Hahnfeld]

Am Mittwoch, den 13.05.2020, 21:54 +0200 schrieb David Kastrup:
> Jonas Hahnfeld <address@hidden> writes:
> > Hi all,
> > 
> > as discussed before the migration, we might want to look into using a
> > CI system. Foremost this would help James who is currently still
> > testing patches manually. At least the doc build can and should be
> > completely automatic.
> > Additionally GitLab has a feature called "Merge Trains", see [1] for
> > the documentation. In short this is a queue of merge requests ready to
> > be merged (Patch::push in our speak). For each of them, GitLab verifies
> > that the potentially merged result passes testing. Only afterwards the
> > change is allowed to hit the target branch. This is basically what the
> > current patchy-staging setup ensures, only at the granularity of merge
> > requests.
> > 
> > That was the nice part in theory. The bad news is that this feature (at
> > the moment) doesn't work well with "Fast-forward merges". In fact,
> > GitLab requires you to rebase your branch (there's a button in the web
> > interface) before merging is allowed.
> > As you can easily imagine, this renders merge trains unusable: Say you
> > have two merge requests and rebased the first to add it to the train.
> > Now you still have to wait for the merge to complete before you can
> > rebase the second.
> 
> Uh, isn't that exactly what we have to do with regard to staging?  The
> only difference is when you take a dare and rebase on a staging branch
> version that has not yet made it to master.  Depending on how testing
> turns out, your rebase may get thrown out along with the actual culprit
> of test failure.

Maybe you're right and I was just overly enthusiastic about getting a
nice queuing mechanism...
In case we only want to apply one merge request at a time, the whole
process gets a lot easier: We don't need a train, but just tell GitLab
that "Pipelines must succeed" before merging is allowed. Together with
only fast-forward merges, this ensures testing of the actual commit
before it hits master. Sounds good from a policy perspective?

> > So the only way out (right now) would be to merge patches instead of
> > ensuring a linear history. This would be radically different from the
> > current process, at the advantage of being "more standard". What do
> > you think about this? (To be honest, I'm not even sure if I like
> > it. But I do like the prospect of having automated testing.)
> 
> At the current point of time, our pipeline does not tend to be all that
> full I think.  We are not at Linux kernel levels of participation...

No, you're probably right. It's only a bit more bothersome if you have
multiple changes to submit from the same countdown.

Jonas

signature.asc
Description: This is a digitally signed message part