On Wed, Nov 11, 2020 at 09:37:53AM +0000, Alex Bennée wrote: > > Philippe Mathieu-Daudé <phi...@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 :|
