lilypond-devel
[Top][All Lists]
Advanced

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

Re: [RFC] Enabling GitLab CI


From: Jonas Hahnfeld
Subject: Re: [RFC] Enabling GitLab CI
Date: Thu, 21 May 2020 18:05:58 +0200
User-agent: Evolution 3.36.2

Am Donnerstag, den 21.05.2020, 17:10 +0200 schrieb David Kastrup:
> 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.

In the current proposal, CI tests those merge requests that target
master. If we allowed others targeting staging without CI, we would be
unable to rely on automated testing. This essentially reduces the net
win of the whole thing to zero.

If we think contention will be a problem, we cannot do the proposal.
There's no sane "mixed bag": As outlined initially, we would 1) require
CI for merge requests, and 2) disable direct pushes to master. This
includes patchy which has no special permissions as far as GitLab is
concerned.

FWIW I don't see much contention at the current rate of development.
See also my other reply to Han-Wen.

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


reply via email to

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