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