Come June 1st (aka very very soon) GitLab will reduce the
CI minutes quota available from 2000 to 400 for public
projects.

The wallclock minutes for CI are the quota divided by
a cost factor currently 0.008. IOW, after June 1st
our allowance reduces from 250,000 wallclock minutes
to 50,000.

While I had intended that we join the OSS program, I'm
unhappy with the financial liability the T&Cs require
us to agree to for tha

Usage stats show we're currently consuming 70-80,000
minutes a month, so we need to cut our usage by at
least 30%.

The main libvirt project is responsible for the vast
majority of usage, so is the biggest quick win, but
we need to economise across all our repos.

With this series, we increase the number of jobs in
the pipeline from 82 to 100, but we mark a great many
of them as manual jobs, so they never run unless a
user explicitly triggers them.

So we have only 54 jobs executing instead of the
original 82. The remaining 46 jobs are optional.
This is a decent win in usage, but we probably need
to cut a little more later to give us breathing space

Daniel P. Berrangé (4):
  ci: refresh with lcitool manifest
  ci: disable native builds on certain distros
  ci: move Ubuntu GCC santizers build to 20.04
  ci: eliminate many cross arch CI builds

 ci/gitlab/build-templates.yml     |  17 ++-
 ci/gitlab/builds.yml              | 246 ++++++++++++++++++++++++++++--
 ci/gitlab/container-templates.yml |   3 +
 ci/gitlab/containers.yml          |  50 +++---
 ci/manifest.yml                   |  59 ++++---
 5 files changed, 329 insertions(+), 46 deletions(-)

-- 
2.36.1

On Fri, May 27, 2022 at 10:06:16AM -0400, Daniel P. Berrangé wrote:
> Come June 1st (aka very very soon) GitLab will reduce the
> CI minutes quota available from 2000 to 400 for public
> projects.
>
> The wallclock minutes for CI are the quota divided by
> a cost factor currently 0.008. IOW, after June 1st
> our allowance reduces from 250,000 wallclock minutes
> to 50,000.
>
> While I had intended that we join the OSS program, I'm
> unhappy with the financial liability the T&Cs require
> us to agree to for tha
>
> Usage stats show we're currently consuming 70-80,000
> minutes a month, so we need to cut our usage by at
> least 30%.
>
> The main libvirt project is responsible for the vast
> majority of usage, so is the biggest quick win, but
> we need to economise across all our repos.
>
> With this series, we increase the number of jobs in
> the pipeline from 82 to 100, but we mark a great many
> of them as manual jobs, so they never run unless a
> user explicitly triggers them.
>
> So we have only 54 jobs executing instead of the
> original 82. The remaining 46 jobs are optional.
> This is a decent win in usage, but we probably need
> to cut a little more later to give us breathing space
>
> Daniel P. Berrangé (4):
>   ci: refresh with lcitool manifest
>   ci: disable native builds on certain distros
>   ci: move Ubuntu GCC santizers build to 20.04
>   ci: eliminate many cross arch CI builds

I'm not entirely convinced this is the exact set of trade-offs we
want, but the new limit is going to be active starting tomorrow so
it's probably a good idea to merge this right away and tweak things
further later, so

  Reviewed-by: Andrea Bolognani <abologna@redhat.com>

Erik, are you okay with this plan? If so, we can push the patches.

-- 
Andrea Bolognani / Red Hat / Virtualization

On Fri, May 27, 2022 at 10:06:16AM -0400, Daniel P. Berrangé wrote:
> Come June 1st (aka very very soon) GitLab will reduce the
> CI minutes quota available from 2000 to 400 for public
> projects.
> 
> The wallclock minutes for CI are the quota divided by
> a cost factor currently 0.008. IOW, after June 1st
> our allowance reduces from 250,000 wallclock minutes
> to 50,000.
> 
> While I had intended that we join the OSS program, I'm
> unhappy with the financial liability the T&Cs require
> us to agree to for tha
> 
> Usage stats show we're currently consuming 70-80,000
> minutes a month, so we need to cut our usage by at
> least 30%.
> 
> The main libvirt project is responsible for the vast
> majority of usage, so is the biggest quick win, but
> we need to economise across all our repos.
> 
> With this series, we increase the number of jobs in
> the pipeline from 82 to 100, but we mark a great many
> of them as manual jobs, so they never run unless a
> user explicitly triggers them.
> 
> So we have only 54 jobs executing instead of the
> original 82. The remaining 46 jobs are optional.
> This is a decent win in usage, but we probably need
> to cut a little more later to give us breathing space

I should have mentioned this is dependant on

  https://gitlab.com/libvirt/libvirt-ci/-/merge_requests/276

without that, instead of getting manual jobs, the jobs disappear
entirely.

With regards,
Daniel
-- 
|: 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 :|