Last week the /qemu-project namespace got added to the GitLab Open Source Program. This gives repos under that namespace extra CI minutes (50,000) and a cost factor of 0.5, meaning in effect 100,000 minutes per month. Primarily this applies to CI pipelines jobs the merge coordinator runs for pull requests via the upstream staging branch.
Joining the OSS program also, however, has a benefit for people who have forks of the /qemu-project/qemu repository. Each user with the free plan normally gets 400 minutes of CI quota per month [1], though some people with older gitlab.com user accounts may still get 2,000 CI minutes / month. Note this quota is across all repos under your /$USERNAME path in gitlab, NOT per repo. You can check your allowance and usage at: https://gitlab.com/-/profile/usage_quotas#pipelines-quota-tab Where things get complicated is the CI cost factor, which varies depending on repo context[2]. Provided your QEMU repo is a fork of /qemu-project/qemu, its CI cost factor should be 0.008. IOW, if you have 400 minutes quota and only run pipelines for QEMU, you should be able to use 50,000 minutes of wall-clock time on shared runners. If your QEMU repo is NOT a fork of /qemu-project/qemu, your CI cost factor will likely be 1. IOW, if you have 400 minutes quota you'll only get 400 minutes of wall-clock time. A QEMU CI pipeline will devour those 400 minutes almost instantly. IOW, it is absolutely critical that your repository is considered a fork of /qemu-project/qemu if you intend to use CI, as it will mean you consume CI quota x125 more slowly. For the majority of contributors this won't be a problem, but a few may have created their QEMU repo before /qemu-project existed on GitLab, and thus not be considerd a fork. To check this, go to the Gitlab web UI for your repo and check that the header says: " Forked from QEMU / QEMU " just underneath the repo description. If it does not say that, then you'll need to rename your existing repo to a different path, and fork from /qemu-project/qemu again. NB, if you exhaust your CI quota, it resets on the 1st of each month. Even with the reduced 0.008 cost factor, QEMU pipelines can consume CI time pretty quickly, so be prudent with what jobs you run. Ensure ***ALL*** your branches are rebased to post v7.1.0 release, before pushing to gitlab, such that they include this commit: commit 28357dc525b4798cdef1101cbb459afcd7233280 Author: Daniel P. Berrangé <berra...@redhat.com> Date: Fri May 27 16:36:02 2022 +0100 gitlab: don't run CI jobs in forks by default This prevents CI pipelines being created merely by pushing the branch. Also avoiding setting 'QEMU_CI=2' when running pipelines, as that triggers every job which will burn alot of CI quota. Best is to use 'QEMU_CI=1' which creates the pipeline but marks all jobs as manual, so you can choose exactly which subset to run. BTW, this largely all applies to other projects on gitlab that use CI too. In libvirt we're switching off CI on push events too, and have also joined the OSS Program to get forks to benefit from reduced cost factor for CI. With regards, Daniel [1] https://about.gitlab.com/pricing/ [2] https://docs.gitlab.com/ee/ci/pipelines/cicd_minutes.html#cost-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 :|
