[libvirt PATCH] ci: mark unstable sid containers as optional

Signed-off-by: Ján Tomko <jtomko@redhat.com> --- .gitlab-ci.yml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index d1609c260d..5e61de3ad8 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -260,7 +260,7 @@ s390x-debian-10-container: NAME: debian-10-cross-s390x aarch64-debian-sid-container: - extends: .container_job + extends: .container_optional_job variables: NAME: debian-sid-cross-aarch64 @@ -275,12 +275,12 @@ armv7l-debian-sid-container: NAME: debian-sid-cross-armv7l i686-debian-sid-container: - extends: .container_job + extends: .container_optional_job variables: NAME: debian-sid-cross-i686 mips64el-debian-sid-container: - extends: .container_job + extends: .container_optional_job variables: NAME: debian-sid-cross-mips64el @@ -295,7 +295,7 @@ ppc64le-debian-sid-container: NAME: debian-sid-cross-ppc64le s390x-debian-sid-container: - extends: .container_job + extends: .container_optional_job variables: NAME: debian-sid-cross-s390x -- 2.31.1

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 -- Andrea Bolognani / Red Hat / Virtualization

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. Pavel

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. -- Andrea Bolognani / Red Hat / Virtualization

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
participants (3)
-
Andrea Bolognani
-
Ján Tomko
-
Pavel Hrdina