On Wed, Aug 18, 2021 at 05:55:09AM -0700, Andrea Bolognani wrote: > On Wed, Aug 18, 2021 at 12:43:21PM +0200, Pavel Hrdina wrote: > > On Wed, Aug 18, 2021 at 02:41:31AM -0700, Andrea Bolognani wrote: > > > On Tue, Aug 17, 2021 at 02:41:48PM +0200, Ján Tomko wrote: > > > > s390x-debian-sid-container: > > > > - extends: .container_job > > > > + extends: .container_optional_job > > > > variables: > > > > NAME: debian-sid-cross-s390x > > > > > > This essentially removes coverage for these architectures in a > > > permanent fashion by sweeping failures under the rug, which is not an > > > acceptable way to deal with a temporary failure IMO. > > > > > > I'm working on a different solution which would retain fully coverage > > > while still working around the current issues with Debian sid. > > > > > > NACK > > > > If I understand this patch correctly it will only mark building the > > container optional, the libvirt build would sill be mandatory so I don't > > see any issue here with coverage. We would simply reuse the latest > > working container to build libvirt. > > That's true, but I'm concerned that in addition to working around > transient issues this will potentially also mask permanent issues > that actually require developer intervention because both would look > exactly the same. > > Additionally, if one were to create a libvirt fork in GitLab right > now their pipeline would fail because there simply wouldn't be a > previous container image to fall back to. Jano pointed out in another thread that we're already treating Rawhide container builds as optional, and since the concerns I mention above would also apply to that situation, dealing with them for Debian only wouldn't make sense and in fact, when a different solution is proposed, it will be helpful that the behavior is consistent for all fast-changing distros. I thus retract my NACK. Please go ahead and merge this patch. -- Andrea Bolognani / Red Hat / Virtualization
