<div dir="ltr"><div dir="ltr">On Mon, Feb 16, 2026 at 3:52 AM Alexander Semke <<a href="mailto:alexander.semke@web.de">alexander.semke@web.de</a>> wrote:</div><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 13/02/26 12:37, Ben Cooksley wrote:<br>
> [...]<br>
> Resource utilisation wise, i've not looked into whether there has been <br>
> a significant bump in the number of jobs, but over the past year some <br>
> additional CD support has been added so that indicates some trouble there.<br>
> System utilisation stats since the start of February are rather telling<br>
><br>
> full_path | time_used | job_count<br>
> ------------------------------+------------------+-----------<br>
> graphics/krita | 228:03:25.300251 | 451<br>
> plasma/kwin | 164:34:16.119352 | 2032<br>
> plasma/plasma-workspace | 136:03:27.534157 | 1044<br>
> multimedia/kdenlive | 113:13:39.087112 | 566<br>
> network/ruqola | 89:02:24.704107 | 369<br>
> pim/messagelib | 83:58:38.936333 | 648<br>
> graphics/drawy | 77:38:55.987716 | 2101<br>
> network/neochat | 76:37:12.290371 | 1069<br>
> plasma/plasma-desktop | 62:27:04.468738 | 619<br>
> utilities/kate | 59:05:46.517227 | 438<br>
> office/kmymoney | 56:58:08.349153 | 241<br>
> education/labplot | 55:19:06.879103 | 423<br>
> frameworks/kio | 43:04:55.33379 | 744<br>
> kde-linux/kde-linux-packages | 39:40:15.332536 | 63<br>
> libraries/ktextaddons | 31:46:16.168865 | 356<br>
> office/calligra | 31:33:35.74806 | 62<br>
> kdevelop/kdevelop | 30:57:38.655126 | 113<br>
> education/kstars | 30:04:42.328143 | 71<br>
> sysadmin/craft-ci | 28:36:13.927477 | 53<br>
> bjordan/kdenlive | 24:13:20.564568 | 191<br>
><br>
><br>
> Contrast that with the full month of September 2025:<br>
><br>
> full_path | time_used | job_count<br>
> -------------------------------+------------------+-----------<br>
> graphics/krita | 382:38:14.237481 | 882<br>
> plasma/kwin | 365:27:01.96681 | 3531<br>
> multimedia/kdenlive | 294:59:01.874773 | 1299<br>
> network/neochat | 233:26:31.601019 | 2298<br>
> packaging/flatpak-kde-runtime | 225:01:38.542109 | 269<br>
> network/ruqola | 219:56:34.415103 | 946<br>
> plasma/plasma-workspace | 194:15:09.699541 | 2014<br>
> sysadmin/ci-management | 118:10:28.754041 | 233<br>
> libraries/ktextaddons | 105:25:58.724964 | 1084<br>
> office/kmymoney | 101:50:27.612055 | 572<br>
> plasma/plasma-desktop | 101:25:05.185953 | 1148<br>
> kde-linux/kde-linux-packages | 101:17:06.284095 | 144<br>
> education/rkward | 84:32:07.118316 | 1033<br>
> kdevelop/kdevelop | 84:04:58.804139 | 270<br>
> utilities/kate | 83:49:15.561603 | 663<br>
> frameworks/kio | 76:46:04.377597 | 1032<br>
> graphics/okular | 74:58:19.8886 | 628<br>
> pim/akonadi | 62:23:56.252831 | 531<br>
> pim/itinerary | 60:05:52.269941 | 578<br>
> network/kaidan | 56:37:44.446695 | 1773<br>
<br>
<br>
Thanks Ben, this is an interesting information. Would it be feasible for <br>
you to send such a report to the mailing list on the monthly base? Or <br>
even add this as the output for every merge request on gitlab? I think <br>
teams can probably easily improve in the various areas, at least in some <br>
of them, and optimize the build and the tests to reduce the overall <br>
runtime. Providing more transparency into the consumption of resources <br>
on CI per project, per job and per test can support such optimizations <br>
and will also help to raise the awareness for the impact of certain <br>
changes on CI.<br></blockquote><div><br></div><div>It has to be manually put together based on queries from the database, so can't be put on every MR.</div><div>It can be run periodically though.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
For me, waiting for CI is really annoying and also disrupting personal <br>
workflows sometimes (waiting today for 3h already in <br>
<a href="https://invent.kde.org/education/labplot/-/merge_requests/845" rel="noreferrer" target="_blank">https://invent.kde.org/education/labplot/-/merge_requests/845</a>, gave up <br>
and switched to a different branch already and will need to go back in <br>
case of errors). For LabPlot we did already multiple optimizations in</blockquote><div><br></div><div>Looks like we dropped 2 runners again (node2 and node3) which i've now revived.</div><div>This hasn't been helped by a number of large projects doing quite a bit of activity today (which is unusual for a Sunday)</div><div><br></div><div><span style="font-family:monospace"><span style="color:rgb(0,0,0)"> full_path | time_used | job_count </span><br>------------------------------------+-----------------+-----------
<br> plasma/plasma-desktop | 07:25:58.851394 | 44
<br> graphics/krita | 07:16:57.78504 | 12
<br> multimedia/kdenlive | 05:17:33.323612 | 30
<br> office/kmymoney | 03:54:42.976902 | 16
<br> pehg/kaidan | 03:16:03.91073 | 30
<br> snap-packaging/kf6-core-sdk | 03:15:04.291499 | 3
<br> system/dolphin | 03:10:27.969557 | 48
<br> utilities/ark | 03:04:04.142 | 33
<br> network/neochat | 02:59:31.366648 | 85
<br> education/labplot | 02:50:22.827995 | 23
<br> libraries/ktextaddons | 02:44:16.520082 | 35
<br> pim/messagelib | 02:17:45.340389 | 14
<br> pim/itinerary | 02:14:12.165157 | 8
<br> cwo/plasma-desktop | 02:09:26.453516 | 7
<br> deeptangshusaha/kdeconnect-android | 01:42:42.818736 | 9
<br> office/skrooge | 01:35:08.920711 | 9
<br> qazcetelic/kdeconnect-android | 01:13:10.125977 | 6
<br> graphics/drawy | 01:11:45.894211 | 44
<br> lito/kdeconnect-kde | 01:06:17.659945 | 24
<br> graphics/digikam | 01:05:11.594924 | 13<br>
<br></span></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br>
the past - not because of the long pending time but just because the <br>
runtime itself was painful and we plan to do another iteration and to <br>
invest more here soon. The problem with the pending time come on top now <br>
and I think teams should check what can be improved here in general <br>
without putting the focus on more hardware only.<br></blockquote><div><br></div><div>Optimisations, especially when they are things that should be done anyway - like removing tests that are broken (timeout, fail) or which don't actually test anything of meaning - are always useful.</div><div><br></div><div>I do believe in this instance there is a hardware element to it - even if it is to simply improve reliability. </div><div><br></div><div>i've noticed that crashes tend to happen most frequently during the launch stage as well, so i'm considering adding locking to vm-runner so only one VM can be starting at any given moment - there is a possibility we are triggering a bug in KVM itself (or elsewhere in the kernel as shipped by Debian). Given the reliability has been declining since the initial introduction of VM based CI i'm not 100% convinced this is the case though.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
-- <br>
<br>
Alexander<br>
<br></blockquote><div><br></div><div>Cheers,</div><div>Ben</div></div></div>