Re: new procedure with GitLab CI

[Jonas Hahnfeld]

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.

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

Jonas

signature.asc
Description: This is a digitally signed message part