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
