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: Daniel P . Berrangé
Subject: Re: [PATCH v2 07/11] acpi/tests/bits: add python test that exercizes QEMU bios tables using biosbits
Date: Tue, 27 Sep 2022 16:45:09 +0100
User-agent: Mutt/2.2.6 (2022-06-05)

On Tue, Sep 27, 2022 at 07:35:13PM +0530, Ani Sinha wrote:
> On Tue, Sep 27, 2022 at 5:12 PM Ani Sinha <ani@anisinha.ca> wrote:
> >
> > On Tue, Sep 27, 2022 at 3:48 PM Daniel P. Berrangé <berrange@redhat.com> 
> > wrote:
> > >
> > > On Tue, Sep 27, 2022 at 03:37:39PM +0530, Ani Sinha wrote:
> > > > > > > > > >
> > > > > > > > > > OK fine. Lets figuire out how to push bits somewhere in 
> > > > > > > > > > git.qemu.org and
> > > > > > > > > > the binaries in some other repo first. Everything else 
> > > > > > > > > > hinges on that. We
> > > > > > > > > > can fix the rest of the bits later incrementally.
> > > > > > > > >
> > > > > > > > > DanPB, any thoughts on putting bits on git.qemu.org or where 
> > > > > > > > > and how to
> > > > > > > > > keep the binaries?
> > > > > > > >
> > > > > > > > Can we please conclude on this?
> > > > > > > > Peter, can you please fork the repo? I have tried many times to 
> > > > > > > > reach
> > > > > > > > you on IRC but failed.
> > > > > > >
> > > > > > > Probably because of travel around KVM forum.
> > > > > > >
> > > > > > > I think given our CI is under pressure again due to gitlab free 
> > > > > > > tier
> > > > > > > limits, tying binaries to CI isn't a great idea at this stage.
> > > > > > > Can Ani just upload binaies to qemu.org for now?
> > > > > >
> > > > > > I agree with Michael here. Having a full ci/cd job for this is
> > > > > > overkill IMHO. We should create a repo just for the binaries, have a
> > > > > > README there to explain how we generate them and check in new 
> > > > > > versions
> > > > > > as and when needed (it won't be frequent).
> > > > > > How about biosbits-bin repo?
> > > > >
> > > > > If QEMU is hosting binaries, where any part contains GPL code, then we
> > > > > need to be providing the full and corresponding source and the build
> > > > > scripts needed to re-create the binary. Once we have such scripts it
> > > > > should be trivial to trigger that from a CI job. If it isn't then
> > > > > we're doing something wrong.
> > > >
> > > > I was thinking of commiting the build scripts in a branch of
> > > > https://gitlab.com/qemu-project/biosbits-bits.
> > > > This would separate them from the main source. The scripts would build
> > > > a version of qemu-bits based on the version information passed to it
> > > > from the environment.
> > > > Before I committed the scripts, I wanted to check whether we would
> > > > want to do that or have a separate repo containing the binaries and
> > > > the build scripts.
> > > > Seems we want the former.
> > > >
> > > > As for the gitlab-ci, I looked at the yaml file and the qemu ones
> > > > looks quite complicated. Can someone help me generate one based on the
> > > > build script here?
> > > > https://github.com/ani-sinha/bits/blob/bits-qemu-logging/build-artifacts.sh
> > >
> > > Yes, QEMU's rules aren't a good place to start if you're trying
> > > to learn gitlab CI, as they're very advanced.
> > >
> > > The simple case though is quite simple.
> > >
> > >   * You need a container image to act as the build env
> > >   * In 'before_script'  install any packages you need on top of the
> > >     base container image for build deps
> > >   * In 'script'  run whatever shell commands you need in order
> > >     to build the project
> > >   * Add an 'artifacts' section to publish one (or more) files/dirs
> > >     as output
> > >
> > > The simplest example would be something like
> > >
> > >    mybuild:
> > >      image: fedora:36
> > >      before_script:
> > >        - dnf install -y gcc
> > >      script:
> > >        - gcc -o myapp myapp.c
> > >      artifacts
> > >        paths:
> > >          - myapp
> > >
> >
> > How does this look?
> > https://pastebin.com/0YyLFmi3
> 
> 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.

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




reply via email to

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