Re: Obstacles for using GitLab CI

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

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

-- 
David Kastrup