Re: new procedure with GitLab CI

[James Lowe]

On 24/05/2020 14:11, Jonas Hahnfeld wrote:
> Am Sonntag, den 24.05.2020, 13:19 +0100 schrieb James Lowe:
> > On 24/05/2020 12:09, Jonas Hahnfeld wrote:
> > > You should see it at the individual MR, can you check
> > > https://gitlab.com/lilypond/lilypond/-/merge_requests/82
> > > ?
> > I am still not certain. Sorry to be a pain here.
> >
> > !83 and !84 show me no pipeline has been run yet the patches are on the
> > list to test.
> The reason is that the branch in !83 is based on a commit 6 days ago,
> before we had CI. This needs a rebase before it's tested.
>
> However, the scripts are working as intended:
> ---
>   $ ./countdown.py --testing
> No patches for testing right now!
> ---
>
> That is even though the MR is in Patch::new. See also below.
>
> > !81 has just now changed from 'unable to get pipeline information' to
> > looking like it has passed
> Yes (thanks Hosoda-san!)
>
> > So, and you didn't answer this specific question, if I set the label to
> > 'review' before the pipeline runs will make doc still run?
> Sorry: Yes, CI pipelines will run irrespective of the labels.
OK. I will try to spot any anomalies on each countdown although I guess 
if something get through to 'push' status and doc has still not been 
tested, then I guess, assuming that the patch breaks make doc, CI will 
fall over.
> > and if it does and it fails will the label change so it doesn't stay in the 
> > county
> > down.
> I will take care of this until I've automated it.
OK.
> > I know we're still finding our feet here, but I need a relatively 'fire
> > and forget' method that doesn't have me hunting around the very busy
> > interface (I have a harder time compared to Allura/Rietveld following
> > discussions nested in amongst a lot of other noise I don't care about).
> See above, the --testing flag should do.
Yes, sorry I keep forgetting this flag.
> > Perhaps we need another 'patch' label, i.e. Patch::new = Patch merged
> > but not doc tested rather than what it is at the moment. Then they can
> > be listed but I don't test them for make check. Then we have a
> > Patch::passed kind of label that I do test and then it moves to 'review'
> > etc.
> Dan also proposed this. My argument against this is that GitLab will
> test every commit, irrespective of the label (see above). In particular
> it will also run the tests on rebase without a diff change where we
> have decided _not_ to change the label.
OK
> On failure, the mode is pretty clear: It should go back to needs_work.
Yes and no more CI is done to it and it comes off my lists.
> But what if a patch in countdown is rebased (without a diff) and is
> currently running? Should it be put back to Patch::new and afterwards
> skip the labels until Patch::countdown? That sounds very confusing to
> me...

I guess that depends on why it was rebased - rhetorical question. But 
shouldn't any rebase be re-tested regardless of a diff or not from 
previous MR after all 'something' has changed else it wouldn't/shouldn't 
be rebased right?

Or are we going to get in to a case where a patch keeps getting pushed 
back because things in front force the rebase each time (if you see what 
I mean?).

As long as we're automating the make doc now, and I don't need to do it 
anymore thereby shaving ~75% off of each patch test now, it still won't 
matter too much to me doing countdown and retesting a 
rebased-but-no-diff patch, but I guess it might annoy the dev.

We'll get there.

James