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 17:10:57 +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, 15:19 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld <address@hidden> writes:
>> > Am Donnerstag, den 21.05.2020, 14:29 +0200 schrieb David Kastrup:
>> > > 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.
>
> No, it doesn't: The MRs must pass CI individually before it can be
> merged.

I did not propose to have CI on staging.

> So it only buys you another test when staging progresses to master.

That was the first, not another test in my plan.

-- 
David Kastrup



reply via email to

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