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:
On Fri, May 29, 2020 at 03:00:42PM +0200, Andrea Bolognani wrote:
+# We build many containers which can be useful to debug problems but are not +# needed for the pipeline itself to complete: those sometimes fail, and when +# that happens it's mostly because of temporary issues with Debian sid. We +# don't want those failures to affect the overall pipeline status +.container_optional_job_template: &container_optional_job_definition + <<: *container_job_definition + allow_failure: true
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
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.
+# Container build jobs + +centos-7-container:
IMHO we should name these to match the build job. eg arch, then distro
x64-centos-7-container
Okay.
+debian-9-cross-armv6l-container: + <<: *container_job_definition + variables: + NAME: debian-9-cross-armv6l
This container, and many others are only used by the "extra" build jobs, so should be subject to the same filtering.
Okay, even though as we discussed separately the whole idea of splitting jobs between regular and extra might be more trouble than it's worth and be more confusing than helpful.
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 :|