Re: FW: Obstacles for using GitLab CI

[David Kastrup]

Carl Sorensen <address@hidden> writes:

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

Not necessarily.  Particularly work where 95% of the work is done by
script and 5% of manual cleanup, merging both commits is not a good
idea.  I usually push those as a merge.  Doesn't strictly help against
hitting the middle with git bisect, but at least it makes it quite clear
what is happening then.

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

I think that this involves making decisions that depend on human
discretion.

-- 
David Kastrup