CI system maintainability

[Konstantin Kharlamov]

On Чт, Mar 28, 2019 at 19:40, Ben Cooksley <bcooksley at kde.org> wrote:
> Hi all,
> 
> 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
> down)
> 
> Regards,
> Ben Cooksley
> KDE Sysadmin

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.

1: 
https://docs.gitlab.com/ee/user/project/merge_requests/merge_when_pipeline_succeeds.html#only-allow-merge-requests-to-be-merged-if-the-pipeline-succeeds