Conserving GitLab CI minutes - check your repo is a true fork

["Daniel P. Berrangé" <berrange@redhat.com>]

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é <berrange@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 :|