Am Mittwoch, den 27.05.2020, 12:17 +0200 schrieb Valentin Villenave: > On 5/27/20, Jonas Hahnfeld <hah...@hahnjo.de> 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
