qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH v2 00/11] Introduce new acpi/smbios python tests using biosbi


From: Michael S. Tsirkin
Subject: Re: [PATCH v2 00/11] Introduce new acpi/smbios python tests using biosbits
Date: Tue, 6 Sep 2022 10:03:55 -0400

On Tue, Sep 06, 2022 at 02:15:41PM +0100, Daniel P. Berrangé wrote:
> On Thu, Jul 14, 2022 at 02:24:18PM +0100, Peter Maydell wrote:
> > On Mon, 11 Jul 2022 at 10:34, Michael S. Tsirkin <mst@redhat.com> wrote:
> > >
> > > On Sun, Jul 10, 2022 at 10:30:03PM +0530, Ani Sinha wrote:
> > > > Changelog:
> > > > v2:
> > > >  - a new class of python based tests introduced that is separate from 
> > > > avocado
> > > >    tests or qtests. Can be run by using "make check-pytest".
> > > >  - acpi biosbits tests are the first tests to use pytest environment.
> > > >  - bios bits tests now download the bits binary archives from a remote
> > > >    repository if they are not found locally. The test skips if download
> > > >    fails.
> > > >  - A new environment variable is introduced that can be passed by the 
> > > > tester
> > > >    to specify the location of the bits archives locally. test skips if 
> > > > the
> > > >    bits binaries are not found in that location.
> > > >  - if pip install of python module fails for whatever reaoson, the test 
> > > > skips.
> > > >  - misc code fixes including spell check of the README doc. README has 
> > > > been
> > > >    updated as well.
> > > >  - addition of SPDX license headers to bits test files.
> > > >  - update MAINTAINERS to reflect the new pytest test class.
> > > >
> > > > For biosbits repo:
> > > >  - added Dockerfile and build script. Made bios bits build on gcc 11.
> > > >    https://github.com/ani-sinha/bits/blob/bits-qemu-logging/Dockerfile
> > > >    
> > > > https://github.com/ani-sinha/bits/blob/bits-qemu-logging/build-artifacts.sh
> > > >    The build script generates the zip archive and tarball used by the 
> > > > test.
> > >
> > > So far so good, I think it's ok for a start. It's probably a good idea
> > > to host the source on qemu.org. Peter - any objection to this?
> > 
> > Dan was looking at v1 from the point of view of how we handle the
> > guest binary blobs for these tests -- I'd rather defer to him rather
> > than taking the time to get up to speed on the issue myself.
> 
> Storing the *source* git repo for biosbits on gitlab.com/qemu-project
> is sensible, as that's what we've done for other 3rd party bits that
> we bundle/depend on git repo access for.
> 
> The above git repo, however, has extra branches that also store the
> binary builds, and I'm not convinced that is a good idea.
> 
> I feel like the source git repo should have a .gitlab-ci.yml file
> that builds the binary and publishes it as an CI artifact. This
> lets us keep the binary outside of GIT, have a CI job that periodically
> refreshes the binary (eg so when the Ubuntu version that Dockerfile
> uses goes EOL we can use something else). The test can access the CI
> artifact directly.
> 
> 
> With regards,
> Daniel

CI is for biosbits developers, bits that everyone uses
is production. I don't think our CI is yet robust enough -
I think when it comes to pushing bits that all
other developers are going to use, it is wise to have them
pushed manually. Random CI failures are not unheard of,
and if these cause a corrupted binary to be downloaded
to all developers, it's going to be bad.



> -- 
> |: 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 :|




reply via email to

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