qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH v2 07/11] acpi/tests/bits: add python test that exercizes QEM


From: Michael S. Tsirkin
Subject: Re: [PATCH v2 07/11] acpi/tests/bits: add python test that exercizes QEMU bios tables using biosbits
Date: Wed, 28 Sep 2022 05:47:09 -0400

On Wed, Sep 28, 2022 at 09:35:59AM +0100, Daniel P. Berrangé wrote:
> On Wed, Sep 28, 2022 at 10:31:39AM +0200, Thomas Huth wrote:
> > On 27/09/2022 23.21, Michael S. Tsirkin wrote:
> > > On Tue, Sep 27, 2022 at 04:45:09PM +0100, Daniel P. Berrangé wrote:
> > > > On Tue, Sep 27, 2022 at 07:35:13PM +0530, Ani Sinha wrote:
> > ...
> > > > > Alright, .gitlab-ci.yml is produced and the pipeline succeeds.
> > > > > However, the question still remains, where do we keep the generated
> > > > > artifacts?
> > > > 
> > > > The following link will always reflect the published artifacts from
> > > > the most recently fully successful CI pipeline, on the 'qemu-bits'
> > > > branch, and 'qemu-bits-build' CI job:
> > > > 
> > > > https://gitlab.com/qemu-project/biosbits-bits/-/jobs/artifacts/qemu-bits/download?job=qemu-bits-build
> > > > 
> > > > Tweak as needed if you push the CI to master branch instead. This
> > > > link can be considered the permanent home of the artifact. I'd just
> > > > suggest that the QEMU job automatically skip if it fails to download
> > > > the artifact, as occassionally transient infra errors can impact
> > > > it.
> > > 
> > > This just means once we change the test old qemu source can no longer use 
> > > it.
> > > Why is this a good idea? Are we so short on disk space? I thought CPU
> > > is the limiting factor?
> > 
> > FYI, we'll soon be short on disk space, gitlab plans to introduce storage
> > limits:
> > 
> >  https://about.gitlab.com/pricing/faq-paid-storage-transfer/
> 
> That's the key reason I prefer the binary as CI artifact rather than
> in Git. Once checked into git, you can never reclaim that storage
> usage, as the git repo is append only, only option is to delete the
> repo and recreate.  With CI artifacts we can control exactly which
> binaries consume storage quota at any time.
> 
> With regards,
> Daniel

I agree binaries in git are a bit of a hack.
But I also feel managing files as part of a test tool is a hack too,
it's an SCM issue.  How about e.g. git-lfs? Seems to be reasonably well
supported on gitlab. There's also gitlab but that seems to be older.


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