Re: [PATCH v2 07/11] acpi/tests/bits: add python test that exercizes QEMU bios tables using biosbits

[Ani Sinha]

On Thu, 6 Oct 2022, Ani Sinha wrote:

>
>
> On Wed, 28 Sep 2022, Michael S. Tsirkin wrote:
>
> > On Wed, Sep 28, 2022 at 11:39:36AM +0200, Thomas Huth wrote:
> > > On 28/09/2022 11.35, Michael S. Tsirkin 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?
>
>
> I did some expriments and it seems we can keep latest artifacts for every
> tagged release of bits. So I have adjusted the yaml file so that everytime
> I push a new tag, a build is
> triggered and the artifacts are preserved without expiry. Ofcourse for
> non-tagged changes, one can trigger the build manually from the web UI as
> well.
>
> For exmaple, this link
> https://gitlab.com/qemu-project/biosbits-bits/-/jobs/3134519120/artifacts/download?file_type=archive
> should download the current artifacts for the tag qemu-bits-latest.
>
> What I am not sure is how to get a downloadable link for the latest build
> for a particular tag without the numeric job ID (which can change across
> builds)? So for example, we can have a consistent URLs to download
> archives
> for every tagged releases and then the test can choose which tagged
> release to
> use. If we can have this then its as good as keeping binaries in a version
> control system like git.


To answer my own question, this is the URL for the qemu-bits-latest tag:

https://gitlab.com/qemu-project/biosbits-bits/-/jobs/artifacts/qemu-bits-latest/download?job=qemu-bits-build

which is the same as

https://gitlab.com/qemu-project/biosbits-bits/-/jobs/artifacts/qemu-bits-09272022/download?job=qemu-bits-build

currently.

If the latest version of bits changes, we can make "qemu-bits-latest" tag
always point to the latest version while artifacts for the older tagged
releases will continue to be available.

danPB, please correct if I am mistaken.

>
> > > > >
> > > > > FYI, we'll soon be short on disk space, gitlab plans to introduce 
> > > > > storage
> > > > > limits:
> > > > >
> > > > >   https://about.gitlab.com/pricing/faq-paid-storage-transfer/
> > > > >
> > > > >   Thomas
> > > >
> > > > A good reason not to use CI artifacts to store images maybe?
> > > > I was proposing storing binaries on qemu.org not on gitlab.
> > >
> > > For qemu.org, you should maybe talk to Paolo and Stefan first, I'm not 
> > > sure
> > > whether we could allow additional network traffic
> > > beside the normal release tarballs there...
> > >
> > >  Thomas
> >
> > I guess we need to design this sensibly to checksum local files
> > and only fetch if there's change, and that only for
> > people who work on ACPI.
> >
> > --
> > MST
> >
> >