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