lilypond-devel
[Top][All Lists]
Advanced

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

Re: Obstacles for using GitLab CI


From: David Kastrup
Subject: Re: Obstacles for using GitLab CI
Date: Thu, 14 May 2020 16:03:41 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Carl Sorensen <address@hidden> writes:

> On 5/14/20, 2:31 AM, "lilypond-devel on behalf of Jonas Hahnfeld"
> <lilypond-devel-bounces+c_sorensen=address@hidden on behalf of
> address@hidden> wrote:
>
> Am Donnerstag, den 14.05.2020, 08:09 +0100 schrieb James:
>> On a more general question, and not really understanding how this CI 
>> workflow will change 'contexturally' what we do, so apologies for if 
>> what I am about to say is ignorant, but are we still taking the 
>> 'master-must-always-be-good' / 
>> 'staging-can-be-bad-because-we-can-force-delete-not-just-revert' approach?
>> 
>> Rather than just automate everything and if something brakes we checkin 
>> a reversion which then makes the tree not 100% compilable?
>> 
>> I've liked that approach we take so far and it always instills a level 
>> of confidence about master.
>
> We would keep 'master-must-always-be-good' but without having an
> explicit staging branch that we need to revert. Instead we ask GitLab
> to only add commits to master after they have passed testing. So
> staging + patchy is basically replaced by merge request + GitLab
> verifying the result of CI. My proposal will hopefully clear this up
> with concrete examples.
>
> -> CS I hope we can get back to the previous mode we worked in that
> not only is master always good, but that every commit on master is
> known to work.

Strange quoting style.  At any rate, it's probably worth stating a few
consequences of our old staging/master setup:

Stuff managed to migrate to master when at least _one_ version of Patchy
had checked it to be good in the tested content.

Patchy, however, is set up in a manner where it picks up work not when
staging is ahead of master, but rather when staging is ahead of its last
tested version.

That means that even if the migration to master may proceed with the
vote of one Patchy, _every_ instance of Patchy will look at whether it
is satisfied with the current state in a timely manner.

So the diversity of our Patchy setups may not keep something working
only on some platforms from getting into master, but it will still not
stay under the radar indefinitely.

-- 
David Kastrup



reply via email to

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