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: > > On Tue, Sep 27, 2022 at 5:12 PM Ani Sinha <a...@anisinha.ca> wrote: > > > > > > On Tue, Sep 27, 2022 at 3:48 PM Daniel P. Berrangé <berra...@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
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? > -- > |: 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 :|
