[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FW: Obstacles for using GitLab CI
From: |
David Kastrup |
Subject: |
Re: FW: Obstacles for using GitLab CI |
Date: |
Thu, 14 May 2020 17:27: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, 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
- Re: Obstacles for using GitLab CI, (continued)
- Re: Obstacles for using GitLab CI, Dan Eble, 2020/05/13
- Re: Obstacles for using GitLab CI, Urs Liska, 2020/05/14
- Re: Obstacles for using GitLab CI, Jonas Hahnfeld, 2020/05/14
- Re: Obstacles for using GitLab CI, James, 2020/05/14
- Re: Obstacles for using GitLab CI, Jonas Hahnfeld, 2020/05/14
- Re: Obstacles for using GitLab CI, James, 2020/05/14
- Re: Obstacles for using GitLab CI, Jonas Hahnfeld, 2020/05/14
- Re: Obstacles for using GitLab CI, Carl Sorensen, 2020/05/14
- Re: Obstacles for using GitLab CI, David Kastrup, 2020/05/14
- Message not available
- Re: FW: Obstacles for using GitLab CI, Carl Sorensen, 2020/05/14
- Re: FW: Obstacles for using GitLab CI,
David Kastrup <=
- Re: Obstacles for using GitLab CI, Jonas Hahnfeld, 2020/05/14