Signed-off-by: Ján Tomko <jtomko(a)redhat.com&gt; --- .gitlab-ci.yml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)

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

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.