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