[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Obstacles for using GitLab CI
From: |
Jonas Hahnfeld |
Subject: |
Re: Obstacles for using GitLab CI |
Date: |
Wed, 13 May 2020 22:43:10 +0200 |
User-agent: |
Evolution 3.36.2 |
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.
Jonas
signature.asc
Description: This is a digitally signed message part
- Obstacles for using GitLab CI, Jonas Hahnfeld, 2020/05/13
- Re: Obstacles for using GitLab CI, David Kastrup, 2020/05/13
- Re: Obstacles for using GitLab CI,
Jonas Hahnfeld <=
- Re: Obstacles for using GitLab CI, David Kastrup, 2020/05/13
- Re: Obstacles for using GitLab CI, Dan Eble, 2020/05/13
- Re: Obstacles for using GitLab CI, Urs Liska, 2020/05/14
- Re: Obstacles for using GitLab CI, Jonas Hahnfeld, 2020/05/14
- Re: Obstacles for using GitLab CI, James, 2020/05/14
- Re: Obstacles for using GitLab CI, Jonas Hahnfeld, 2020/05/14
- Re: Obstacles for using GitLab CI, James, 2020/05/14
- Re: Obstacles for using GitLab CI, Jonas Hahnfeld, 2020/05/14
- Re: Obstacles for using GitLab CI, Carl Sorensen, 2020/05/14
- Re: Obstacles for using GitLab CI, David Kastrup, 2020/05/14