>From time to time it happens that some of the distros for which we run our pipelines break (or the images we pull break). Because we don't have dedicated maintainers for the jobs/runners, we can only employ the best effort approach wrt to making the pipeline green again when we're positive the problem doesn't lie in libvirt. For jobs that are broken for quite some time we should opt to disable them unconditionally unless a volunteer dedicates the time to either fix it or the matter gets fixed on its own in time (e.g. updated container images). GitLab only provides the "only/except" keywords to conditionally run or skip jobs. However, the problem with this is that since the job is not scheduled, = it won't appear in the pipeline output, so it's by no means clear to an outsider looking at the pipeline that something "is missing" in the UI. There have been a few open feature requests to incorporate exit status reporting for jobs and their interpretation in the pipeline output [1], but the community has been waiting for this for over 4 years already. As for patch 2, I spent some time this morning to figure out why the FreeBSD jobs were failing, not knowing the qemu-utils package is not outdated and surpassed by the qemu package in port. As a result I intended to disable the FreeBSD jobs until the maintainers flip the qemu-utils package from BROKEN to available again. Now that Dan solved the problem in libvirt-ci, I only left it there for trivial demonstration purposes. [1] https://gitlab.com/gitlab-org/gitlab-foss/-/issues/25738 Erik Skultety (2): gitlab-ci.yaml: Introduce a variable to disable long broken jobs DO NOT MERGE: Showcase a disabled job .gitlab-ci.yml | 14 ++++++++++++++ 1 file changed, 14 insertions(+) --=20 2.29.2