lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] Enabling GitLab CI


From: David Kastrup
Subject: Re: [RFC] Enabling GitLab CI
Date: Thu, 21 May 2020 15:19:30 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Jonas Hahnfeld <address@hidden> writes:

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

It buys you that several commits are bunched in staging and are treated
in bulk.  At least I think it does.

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

I was more going for the mixed bag right now :)

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]