lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] Enabling GitLab CI


From: Jonas Hahnfeld
Subject: Re: [RFC] Enabling GitLab CI
Date: Mon, 18 May 2020 11:29:35 +0200
User-agent: Evolution 3.36.2

Am Sonntag, den 17.05.2020, 21:14 +0100 schrieb James Lowe:
> On 17/05/2020 20:27, Jonas Hahnfeld wrote:
> >   - Comparison of regression tests is not yet integrated, the main
> > problem being the need for a baseline. I already have an idea or two
> > how this could work, but for now I'm focusing on the initial setup.
> > This means James still needs to download the patches and run 'make
> > check' (make doc being run automatically).
> 
> Yes that would save me time.
> 
> Something that strikes me immediately.
> 
> * If a CI run makes doc are we going to have an entry and or label in 
> the comment for a success/failure?
> 
> I don't want to bother with any test if make/make doc fails, so I assume 
> that it will change the label to take it off patch new. But at the same 
> time if a patch is 'new' and hasn't had the make/make doc test, do I 
> still run the make check anyway? If so then it passed the label would go 
> to review and I assume the CI run would still catch that and do the 
> make/make doc. Otherwise I am going to not only have to check for a 
> patch 'new' I am going to have to know that it is waiting on a make doc 
> first if you see what I mean? (will I have to second guess the CI so to 
> speak)

I'm not sure I fully understand the question(s).

First of all, the system tests every new commit added to a merge
request, no matter how small or if the diff is the same as before.
(That's the advantage of computers, they don't get bored at doing the
same over and over again.) If the tests pass, you get nice green ticks
everywhere. On error GitLab shows red crosses instead, in particular
the stage that failed (build, test, doc). This currently doesn't add
the Patch::needs_work label, but I can certainly make our bot do this.

As the pipelines start immediately after the push, they might already
be finished when you look at the merge request. If something didn't
pass, I think it's perfectly ok to skip manual tests.
In case the pipelines are still running or even pending, I think you
should ignore that merge request for the time being and maybe come back
later. We'll see how much of an issue this turns out to be.

Regards
Jonas

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]