Obstacles for using GitLab CI

[Jonas Hahnfeld]

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. GitLab devs intend to make this work better in the
future [2][3], but that's already in discussion for some time.

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

Regards
Jonas


1: 
https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/
2: https://gitlab.com/gitlab-org/gitlab/-/issues/35628
3: https://gitlab.com/gitlab-org/gitlab/-/issues/895

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