Re: new procedure with GitLab CI

[David Kastrup]

Jonas Hahnfeld <address@hidden> writes:

> Am Mittwoch, den 27.05.2020, 12:17 +0200 schrieb Valentin Villenave:
>> On 5/27/20, Jonas Hahnfeld <address@hidden> wrote:
>> > We do want to have the pipeline on the commit before it is merged
>> > because this replaces patchy.
>> 
>> Well, that’s absolutely crucial at the MR review stage. But after
>> passing the review and countdown process, the need for CI
>> testing decreases.  So an option to bypass the pipeline when we reach
>> the “rebase & merge” stage wouldn’t necessarily be harmful.
>
> [added the part of the second email]
>
> This would be radically different from the old setup: Push to staging,
> wait for patchy to test. I agree that not bunching stuff together is
> different, but no testing at all isn't an alternative IMHO.

Now that we have the first "please get in line" merge that isn't
actually to any degree unusual, I get the suspicion that my previous
alternative proposal of pushing to a CI-less staging branch that then
uses CI to get to master will eventually become a reality.

The main question is then rather whether this should be optional (in
which case someone needs to be responsible for rebasing the collected
staging when something got to master directly) or mandatory after all.

>> > The only limitation is that all MRs are
>> > checked individually.
>> 
>> Not only individually, but sequentially.  And with no automatic queue
>> for rebasing, everything has to be done manually: checking whether
>> something’s already running somewhere; waiting until that gets merged;
>> then triggering the rebase/CI while hoping nobody else has been doing
>> the same at the same moment.
>> 
>> That’s not merely a limitation, that’s a PITA.  Is there a way we
>> could at least get the rebase part done within the pipeline? i.e.
>> “rebase and launch pipeline and merge when the pipeline is done” or
>> something like that?
>
> No, "rebase" is currently manual (with "merge when pipeline succeeds"
> being automatic). This has been clearly communicated, sorry if you
> missed that.

Well, the point of a working mechanism is that nothing needs to get
communicated by side channels.  Of course, we aren't there yet since we
are still figuring out our usage patterns for Gitlab.

> Jonas
>

-- 
David Kastrup