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
