Re: Obstacles for using GitLab CI

[David Kastrup]

Jonas Hahnfeld <address@hidden> writes:

> 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.

The real problem starts when people don't manage to get their patch in
because the pipeline is always busy.  But if we are there, the free CI
plan will most certainly not do the trick anymore.

-- 
David Kastrup