<div dir="ltr"><div dir="ltr">On Tue, May 6, 2025 at 5:36 AM Volker Krause <<a href="mailto:vkrause@kde.org">vkrause@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">On Freitag, 2. Mai 2025 22:55:34 Mitteleuropäische Sommerzeit Ben Cooksley <br>
wrote:<br>
> On Sat, May 3, 2025 at 8:26 AM Christoph Cullmann <<a href="mailto:christoph@cullmann.io" target="_blank">christoph@cullmann.io</a>><br>
> <br>
> wrote:<br>
> > On Friday, May 2nd, 2025 at 22:18, Ben Cooksley <<a href="mailto:bcooksley@kde.org" target="_blank">bcooksley@kde.org</a>> wrote:<br>
> > <br>
> > On Sat, May 3, 2025 at 3:27 AM Christoph Cullmann <<a href="mailto:christoph@cullmann.io" target="_blank">christoph@cullmann.io</a>><br>
> > <br>
> > wrote:<br>
> >> Hi,<br>
> >> <br>
> >> at work we use cmake unity build to save time & costs.<br>
> >> <br>
> >> Would that be some idea here, too?<br>
> >> <br>
> >> Naturally as side effect that can hide compile issues<br>
> >> or introduce ones.<br>
> > <br>
> > We could look into that, just not sure how it would save compile times<br>
> > though?<br>
> > We have extremely fast NVMe storage on the builders, so we're unlikely to<br>
> > be IO constrained.<br>
> > <br>
> > <br>
> > Hi,<br>
> > <br>
> > that saves more compute power than IO, you parse headers just 1/x of the<br>
> > time for x sized units<br>
> > and you spawn just 1/x of the processes, at work, that leads to 2 or 4<br>
> > times the speed, on bare metal<br>
> > machines with only SSDs, too.<br>
> > <br>
> > But naturally that will depend on the projects.<br>
> <br>
> I see. Based on the CMake documentation it sounds like something that<br>
> doesn't always work so i'm hesitant to enable it as a global flag.<br>
> The CI system through the option cmake-options in .kde-ci.yml can allow for<br>
> the necessary unity build flags to be passed - so this is something heavy<br>
> users with lots of files may want to look into.<br>
<br>
Right, this is probably not a suitable default.<br>
<br>
What might be worth exploring though is using unity builds for QML cachegen <br>
code by default. That's many somewhat uniform and predictable files with the <br>
same includes etc. And at least for several things in the top 20 those files <br>
are a significant part of the cost.<br></blockquote><div><br></div><div>This sounds like something that needs to be sorted within ECM / Frameworks / the applications themselves though and isn't something that can be done at a global CI level?</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>
Regards,<br>
Volker<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>
> >> On Friday, April 18th, 2025 at 21:25, Ben Cooksley <<a href="mailto:bcooksley@kde.org" target="_blank">bcooksley@kde.org</a>><br>
> >> wrote:<br>
> >> <br>
> >> Hi all,<br>
> >> <br>
> >> Over the past week or two there have been a number of complaints<br>
> >> regarding CI builder availability which i've done some investigating into<br>
> >> this 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<br>
> >> 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<br>
> >> be<br>
> >> found in all projects.<br>
> >> <br>
> >> When reviewing the list of CI builds projects have enabled, it is<br>
> >> important to consider to what degree your project benefits from having<br>
> >> various builds enabled. One common pattern i've seen is having Alpine,<br>
> >> SUSE<br>
> >> Qt 6.9 and 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<br>
> >> a 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<br>
> >> are made in stable then immediately merged to master in a ever continuing<br>
> >> loop. Please discontinue this behaviour and only periodically merge<br>
> >> stable<br>
> >> to 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>
> >> Thanks,<br>
> >> Ben<br>
<br>
</blockquote></div></div>