<div dir="ltr"><div dir="ltr">On Sun, Apr 20, 2025 at 9:10 PM Albert Astals Cid <<a href="mailto:aacid@kde.org">aacid@kde.org</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">El divendres, 18 d’abril del 2025, a les 21:25:36 (Hora d’estiu d’Europa <br>
central), Ben Cooksley va escriure:<br>
> Hi all,<br>
> <br>
> Over the past week or two there have been a number of complaints regarding<br>
> CI builder availability which i've done some investigating into this<br>
> morning.<br>
> <br>
> Part of this is related to the Windows CI builders falling offline due to<br>
> OOM events, however the rest is simply due to a lack of builder time<br>
> availability (which is what this email is focused on).<br>
> <br>
> Given we have 6 Hetzner AX51 servers connected to Gitlab (each equipped<br>
> with a Ryzen 7 7700 CPU, 64GB RAM and NVMe storage) the issue is not<br>
> available build power - it is the number of builds and the length of those<br>
> builds that is at issue.<br>
> <br>
> This morning I ran a basic query to ascertain the top 20 projects for CI<br>
> time utilisation on <a href="http://invent.kde.org" rel="noreferrer" target="_blank">invent.kde.org</a> which revealed the following:<br>
> <br>
> full_path | time_used | job_count<br>
> ------------------------------+------------------+-----------<br>
> plasma/kwin | 320:47:04.966412 | 2387<br>
> graphics/krita | 178:03:19.080763 | 423<br>
> multimedia/kdenlive | 174:08:09.876842 | 697<br>
> network/ruqola | 173:17:47.311305 | 555<br>
> plasma/plasma-workspace | 155:10:03.618929 | 660<br>
> network/neochat | 138:03:23.926652 | 1546<br>
> education/kstars | 129:49:17.74229 | 329<br>
> sysadmin/ci-management | 111:21:09.739792 | 154<br>
> plasma/plasma-desktop | 108:56:52.849433 | 776<br>
> kde-linux/kde-linux-packages | 81:00:10.001937 | 33<br>
> kdevelop/kdevelop | 59:40:51.54474 | 217<br>
> office/kmymoney | 54:32:00.24623 | 271<br>
> frameworks/kio | 53:54:19.046685 | 690<br>
> education/labplot | 52:36:30.343671 | 245<br>
> murveit/kstars | 52:32:56.882728 | 128<br>
> frameworks/kirigami | 47:07:19.172935 | 1627<br>
> system/dolphin | 46:09:58.02836 | 705<br>
> kde-linux/kde-linux | 39:25:54.052469 | 46<br>
> utilities/kate | 36:09:22.18958 | 356<br>
> wreissenberger/kstars | 35:58:14.120515 | 105<br>
> <br>
> If we look closely, KStars has three spots on this list (totalling 216<br>
> hours of time used, making it the biggest app user of CI time).<br>
> <br>
> Projects on the above list are asked to please review their jobs and how<br>
> they are conducting development to ensure CI time is used efficiently and<br>
> appropriately.<br>
> <br>
> Other projects should also please review their usage and optimise<br>
> accordingly even if they're not on this list as there is efficiencies to be<br>
> found in all projects.<br>
> <br>
> When reviewing the list of CI builds projects have enabled, it is important<br>
> to consider to what degree your project benefits from having various builds<br>
> enabled. One common pattern i've seen is having Alpine, SUSE Qt 6.9 and<br>
> SUSE Qt 6.10 all enabled.<br>
> <br>
> If you need to verify building on Alpine / MUSL type systems and wish to<br>
> monitor for Qt Next regressions then you probably shouldn't have a<br>
> conventional Linux Qt stable build as those two jobs between them already<br>
> cover that list of permutations.<br>
> <br>
> I've taken a quick look at some of these and can suggest the following:<br>
> <br>
> KWin: it has two conventional Linux jobs (suse_qt69 and suse_qt610) plus a<br>
> custom reduced feature set job. It seems like one of these conventional<br>
> Linux jobs should be dropped.<br>
> <br>
> KStars: Appears to have a custom Linux job in addition to a conventional<br>
> Linux job. Choose one please.<br>
> <br>
> Ruqola: Appears to be conducting a development process whereby changes are<br>
> made in stable then immediately merged to master in a ever continuing loop.<br>
> Please discontinue this behaviour and only periodically merge stable to<br>
> master.<br>
> <br>
> Also needs to drop one of it's Linux jobs as they're duplicating<br>
> functionality as noted above.<br>
> <br>
> Plasma Workspace/Desktop: At least in part this seems to be driven by<br>
> Appium tests. Please reduce the number of these and/or streamline the<br>
> process for running an Appium test. Consideration should be given to<br>
> enabling the CI option use-ccache as well.<br>
> <br>
> KDevelop: Please enable the CI option use-ccache.<br>
> <br>
> Labplot: Appears to have a strange customisation in place to the standard<br>
> jobs which shouldn't be necessary as flags in .kde-ci.yml should permit<br>
> that to be done.<br>
<br>
I don't understand why you are putting this kind of pressure when we could <br>
disable the "run CI when someone pushes into a work branch (or non main repo) <br>
without creating an MR" and save like 50% of CI time.<br></blockquote><div><br></div><div>Because then those people who are using work branches without a merge request are left high and dry.</div><div>This workflow has been used many times for CI testing.</div><div><br></div><div>I'd have to run the numbers, but as noted above, one project is 9% of the CI utilisation....</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>
Cheers,<br>
Albert<br></blockquote><div><br></div><div>Cheers,</div><div>Ben</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>
> Thanks,<br>
> Ben<br>
<br>
<br>
<br>
<br>
</blockquote></div></div>