On Чт, Mar 28, 2019 at 19:40, Ben Cooksley <bcooks...@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