Re: CI system maintainability
- Date: Thu, 28 Mar 2019 09:55:44 +0300
- From: Konstantin Kharlamov <hi-angel@xxxxxxxxx>
- Subject: Re: CI system maintainability
On Чт, Mar 28, 2019 at 19:40, Ben Cooksley <bcooksley@xxxxxxx> wrote:
We currently have a rather substantial issue, in that the CI system
has been once again left in a position where it isn't possible to make
any changes to the system.
This means we can't update to newer versions of packages, add new
packages or correct for binary incompatible changes which periodically
get introduced to non-Frameworks.
This issue has arisen because currently we have a recurring failure to
build from source, within KDE PIM. Specifically, KContacts fails due
to broken CMake logic. Despite this breakage having been in place for
several days now, and the relevant mailing list being informed
automatically by the CI system, the issue has not been corrected.
While the most immediate fix is to correct this failure to build from
source, that is only a short term fix and does not fix the underlying
issue which makes the CI system difficult to maintain - and that is
build failure reports being ignored, and people pushing broken code
that doesn't even build.
(For those wondering, the CI system uses OpenSUSE Tumbleweed, a
rolling release distribution, for it's builds, so it isn't a case of
old CMake or anything along those lines)
We therefore need a long term fix for this. Note that pre-commit (as
part of review) CI is not a solution in this instance, as the
offending commits did not go through review.
Does anyone have any ideas for a long term, proper fix to this?
At this point given the amount of effort required to maintain a CI
system vs. the amount of care actually being given by some developers
(who are ignoring it's failure emails) it becomes questionable whether
the effort is worth the return (and if not, we should just shut it
I don't know abut the current CI, but judging by recent discussion that
is about KDE migrating to gitlab; quick search shows gitlab does allow
prohibiting a merge if CI failed¹
Note however, in my experience of contributing to diffrent project CI
often fails for reasons absolutely irrelevant to code being tested
(e.g. errors in a CI script), in this case prohibiting a merge may
worsen the situation.