Re: Obstacles for using GitLab CI

[Carl Sorensen]

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.

-> CS  As I have been verifying issues fixed for 2.20.1 I have found a number 
of issues that were resolved with 2, 3, 4, or as many as 7 commits.  As far as 
I know, we have no testing that indicates each of these commits builds 
correctly, only that the full set of commits builds correctly.  We made a 
conscious decision to require only single-commit fixes so that every commit on 
master would build, and we could use git-bisect effectively to identify 
regressions.

-> CS  I know that we had some discussion about how it is much more convenient 
to have multiple small commits for reviewing, and I can see that in nearly 
every case the multiple commits were aimed at helping reviewers understand the 
patches, which I think is a great thing.  I'd be happy to keep multiple commits 
for reviewing, but I believe we need to ensure that every commit on master 
builds properly to support git-bisect.

-> CS  I hope that we can make our CI/merge process function such that either 
we run the CI on every commit in a merge request or we rebase/squash/make a 
single merge commit so that the intermediate, untested commits do not show up 
on master.

-> CS  Thanks, Jonas for your hard work on this.  I think this will be a great 
step forward.

Carl