On Wed, Jun 10, 2026 at 02:21:33PM +0200, Kevin Wolf wrote: > Am 10.06.2026 um 13:48 hat Daniel P. Berrangé geschrieben: > > On Wed, Jun 10, 2026 at 01:39:16PM +0200, Kevin Wolf wrote: > > > Am 10.06.2026 um 13:17 hat Daniel P. Berrangé geschrieben: > > > > You just got unlucky with the new expanded CI testing introduced when > > > > my pull request was merged a few days ago. Previously gitlab CI only > > > > tested qcow2 and raw, and so compat with other drivers was "best effort" > > > > after the fact. > > > > > > > > Now the gitlab CI runs I/O tests across 10 drivers, so it needs to > > > > work before merge, which is something contributors didn't need to > > > > think about before now. > > > > > > > > If you push a branch to your gitlab fork and trigger CI, you'll see > > > > the results in the "block" job in the pipeline results. > > > > > > Technically true, but who has the CI minutes to actually do this? > > > > Pretty much everyone IMHO. > > > > > I don't think we've figured out a solution yet how people (or at least > > > maintainers) can use QEMU's minutes from the open source program prior > > > to sending a patch series or pull request. Or have we? > > > > GitLab user accounts get 400 minutes of CI credits. > > > > Forks of QEMU though are only charged at a cost fact or 0.008 since > > we are a member of the OSS program > > > > > > https://docs.gitlab.com/ci/pipelines/compute_minutes/#cost-factors-of-hosted-runners-for-gitlabcom > > > > IOW, you're charged 1 minute per 125 minutes of job time. > > > > A single QEMU pipline run in my fork today cost 4.5 credits. That's > > enough for 87 pipeline runs per month, if I was not contributing to > > anything outside QEMU on gitlab.com. > > > > If you run a pipeline to sanity check before sending a patch series > > I don't think most people will ever run out of credits. > > > > If you run multiple pipelines a day during development then you might > > be pushing your luck. Better to use the local "make docker-...." > > targets for day-to-day testing during dev, and just use gitlab > > pipelines before submission. > > Did this change at some point? Because I'm quite sure I stopped doing > full CI runs only after running out of minutes with very moderate use. > Ever since then, I've only manually started individual jobs when I had > reason to suspect there could be a problem with them.
Yes, there was a time window when QEMU was *not* part of the OSS program and so forks would get charged at the full 1:1 rate. At the same time gitlab was transitioning personal accounts from two different CI limits, so those with newer accounts would run out much faster due to a lower limit than other people with older accounts like myself. Everyone now has the same 400 minute limit, with the 0.008 cost factor inherited. The only caveat is that your git repo *MUST* be a direct fork of qemu-project/qemu.git in order to inherit the cost factor. So, yes, there were problems in the past, but it should be much better for most people today. And we do have the "QEMU_CI=1" push option to trigger individual jobs manually vs "QEMU_CI=2" run unleashes the whole pipeline, so users can conserve CI credits if debugging a specific job over & over again. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
