Am Mittwoch, den 13.05.2020, 21:54 +0200 schrieb David Kastrup: > Jonas Hahnfeld <hah...@hahnjo.de> 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