Re: FW: Obstacles for using GitLab CI

[Carl Sorensen]

> On 5/14/20, 8:04 AM, "David Kastrup" <address@hidden> wrote:
>
> 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:


Yes.  I have been using Microsoft Outlook due to our standards at work.
Microsoft has disabled internet quoting style in Outlook 2016 for MacOS.
This alternative was proposed by Werner.  I've finally decided it's more
bother than changing my lilypond-devel subscription to Gmail and using a
different mail client for my LilyPond work.


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

I think you have not understood the issue with which I am concerned.
Suppose I have a fix for an issue that contains six commits.  The first 3
result in failure to make doc.  The last 3 fix the problem.  So after the
set of 6 commits, everything is good.

Under our past standards, I would be expected to rebase those six commits
into a single commit and push to staging.  Thus, staging builds.

Many of the commits I have been verifying from the last year have not
rebased those six commits into a single commit.  The six individual commits
are pushed to staging, each with its own commit ID.  But since they are all
pushed at one time, Patchy never tests the state after commit 2.

Now, a year later, we're trying to find a regression.  We're using
git-bisect.   git-bisect lands on commit 2 and tries (and fails) to build.
This messes up my git-bisect run, and I have to deal with things manually.

My request is that we have some way of preventing this problem by either
(a) having our CI test each of my six commits and finding out that 3 of
them fail, thus requiring me to rebase before the PR is accepted; or (b)
having an automated merge process that combines my six commits into a
single commit and then tests it with CI to demonstrate that it passes, and
only the combined commit gets sent to master.

Thanks,

Carl