[libvirt PATCH 3/5] ci: Use GitLab container registry

Andrea Bolognani abologna at redhat.com
Tue Jun 2 12:45:30 UTC 2020


On Tue, 2020-06-02 at 12:23 +0100, Daniel P. Berrangé wrote:
> On Tue, Jun 02, 2020 at 01:10:08PM +0200, Andrea Bolognani wrote:
> > On Tue, 2020-06-02 at 11:33 +0100, Daniel P. Berrangé wrote:
> > > I don't think we should be building container images that we're not going
> > > to be using in any of the jobs, as it can only ever slow down the build
> > > overall.
> > 
> > These same containers are also available for use outside of CI, eg.
> > with 'make ci-build', so I think we should keep building them.
> 
> That only needs them built on the master branch of the main repo
> though, not every branch in every fork

Fair enough. So what you're suggesting is something like

  .container_optional_job_template: &container_optional_job_definition
    <<: *container_job_definition
    allow_failure: true
    except:
      variables:
        - $CI_PROJECT_NAMESPACE != libvirt
    only:
      - master

correct?

> > As for slowing down builds, that still only applies to the first
> > build after Dockerfiles are updated, so I don't think it ultimately
> > matters very much.
> 
> I'd expect a rebiuld if the distro base image changes which could
> be fairly often for the rawhide like distros.

This advantage might be cancelled out by the fact that only a limited
number of shared runners is available, so if for example we have
access to 5 runners, whether we run 6 or 10 jobs will make no
difference in terms of total pipeline completion time.

-- 
Andrea Bolognani / Red Hat / Virtualization




More information about the libvir-list mailing list