Re: [RFC] Enabling GitLab CI

[Jonas Hahnfeld]

Am Donnerstag, den 21.05.2020, 14:29 +0200 schrieb David Kastrup:
> Jonas Hahnfeld <address@hidden> writes:
> > Am Dienstag, den 19.05.2020, 08:08 -0400 schrieb Dan Eble:
> > > On May 17, 2020, at 15:27, Jonas Hahnfeld <address@hidden> wrote:
> > > > before merging. As we only allow fast-forward merges, this means each
> > > > MR has received testing in the form it hits master. This would
> > > > effectively replace the current setup of pushing to staging.
> > > 
> > > I'm for this.
> > 
> > Thanks. What do others (David, Han-Wen, Valentin) think about this?
> > There's certainly room for improvement, but with an initial setup I can
> > start writing documentation.
> 
> The "traffic jam" problem could be avoided by retaining the option of
> pushing to staging.  That would occur without CI, but one could
> occasionally trigger the merge with CI on staging to have everything in
> it migrate to master.  Since staging would be used by the more
> experienced people desiring to bunch their work before testing, the
> triggering could also happen manually by whoever thinks he has pushed
> enough stuff to staging to give it a whirl.

That's not really how CI works. With our policy of FF merges, what
happens if some MR get merged directly to master and some sit in
staging? You'd probably rebase staging which triggers another CI
pipeline and doesn't buy you much.

I generally agree that there's a potential for contention. However
we're aiming for ~1h of CI which means we can merge many more patches
than we currently have per countdown. Merging patches doesn't need to
happen the minute James' message hits lilypond-devel, I think doing
this some time until the next countdown should be fine.

I don't mind deciding that we don't want to enable CI right now. The
purpose of bringing this up now is that I didn't want to spend time
documenting something that's going to change the next day. In my opinion, 
having CI and merging to master feels more "natural" than the staging setup. 
And finally if contention proves to be a problem, we can still revert to the 
old setup.

Jonas

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