Re: [RFC PATCH 10/16] gitlab-ci: Introduce the CI "job maintainer" concept

From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: "Fam Zheng" <fam@euphon.net>, "Thomas Huth" <thuth@redhat.com>,
	"Stefan Weil" <sw@weilnetz.de>,
	"Bin Meng" <bin.meng@windriver.com>,
	"Michael Tokarev" <mjt@tls.msk.ru>,
	qemu-devel@nongnu.org,
	"Wainer dos Santos Moschetta" <wainersm@redhat.com>,
	"Laszlo Ersek" <lersek@redhat.com>,
	virt-ci-maint-team@redhat.com, "Bin Meng" <bmeng.cn@gmail.com>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>
Subject: Re: [RFC PATCH 10/16] gitlab-ci: Introduce the CI "job maintainer" concept
Date: Wed, 11 Nov 2020 09:53:55 +0000	[thread overview]
Message-ID: <20201111095355.GB906488@redhat.com> (raw)
In-Reply-To: <87o8k46xou.fsf@linaro.org>

On Wed, Nov 11, 2020 at 09:37:53AM +0000, Alex Bennée wrote:
> 
> Philippe Mathieu-Daudé <philmd@redhat.com> writes:
> 
> > When a job fails, someone has to take care of it. As we can
> > not wait indefinitively of volunteers good will, introduce the
> > concept of "job maintainers". A job maintainer is reponsible
> > of keeping it working, or contact the developers having broken
> > it to fix it.
> >
> > When a job is added, it must have a maintainer. A job without
> > maintainer is not run automatically. It can however be run
> > manually from the WebUI.
> >
> > To declare a maintainer, it is as easy as defining the
> > JOB_MAINTAINER_NAME / JOB_MAINTAINER_EMAIL environment variables.
> 
> So I think the problem here is the CI jobs are orthogonal to the actual
> tests. And the tests should be associated via MAINTAINERS with the
> relevant sub-systems.
> 
> That is not to say that the test environments don't need some care and
> attention. So I'm quite happy to track updates needed to
> tests/docker/dockerfiles for example but just because check-block failed
> on an Ubuntu system doesn't mean I'm best placed to diagnose the
> problem. In the first instance it shouldn't happen (not merging code
> that regresses a test) and the second instance probably requires a block
> maintainer to look at the output.
> 
> I think a better solution is to improve our test reporting so we can
> quickly point the failing tests. I notice GitLab gets nice test output
> from check-acceptance. What would we need to do to improve it from
> check, check-block and check-tcg?

That presentation is from the artifacts publishing test results
in junit format. IOW, we need to enhance the build system in some
way such that it can generate a junit report of other tests too.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|