Deploy stage manually on master, unit test build time technologies (was: Re: Excessive tests in Ruqola [...])

Hi all,

Am Donnerstag, 16. Juli 2026, 13:35:05 Mitteleurop=C3=A4ische Sommerzeit sc=
hrieb=20
Ben Cooksley:
> Over the past week or two Sysadmin has received a number of complaints
> regarding a lack of CI builder availability, primarily from those who work
> on Plasma. Investigation has revealed that Ruqola appears to use a
> disproportionately high amount of CI time compared to the size of the
> project and it's activity.
>=20
> This appears to be driven by the fact that Ruqola has a large number of
> tests that do not take very long to execute (700 or so tests, yet done in=
=20
6
> minutes - with many of these being less than 1 second to run). Given that
> every single one of these unit tests needs to have automoc / compiler /
> linker run on it i'd suggest that similar tests be merged into the same
> compilation unit (you can run the individual tests, but keep similar tests
> together in the same unit test). This would also explain why the build=20
time
> on Windows is significantly longer, as NTFS does not perform well when
> compared to Linux file systems, even on NVMe storage.

DEPLOY STAGE "TESTS"

When it comes to "Excessive tests" could we please also consider to make fo=
r=20
master/development/MR branches the "Deploy" stage on-demand, instead of=20
always running it together with the "Build" stage? That would scale across=
=20
all apps. And by my rough estimate by some samples I looked at save half of=
=20
those projects' CI time. And most activity happens on master/development/MR=
=20
branches, so this would scale even more.
=46or release branches always running the deploy stage seem reasonable, the=
re=20
one wants to properly check everything as early as possible for regressions.

=46rom what I understand, those package builds (on master/development/MR=20
branches) are just done to test if packaging still works. So a plain test=20
run, just on package level. Taking roughly the full time of the normal=20
build. Sometimes even (much) longer, despite not building also normal (unit=
)=20
tests and running them.

I very doubt that the resulting package artifacts on those branches are=20
actually used by anyone on a regular basis. There is no official CD also, i=
s=20
there? (Nothing related spotted on apps.kde.org or heard about). So it seem=
s=20
just a "does it package" test. With massive resource usage tag, outnumberin=
g=20
any normal unit tests.

So could we please reduce the test package/deploy builds on master?
Make them manually activateable only, and perhaps have them run=20
automatically only as part of the weekly "Albert" run? Or as part of some=20
nightly CD system at some point?

Again, not done the full numbers, but my gut feeling from those samples I=20
saw is that this will have a noticeable effect on CI resource uages.


TESTS RUN ONLY ON ONE PLATFORM

Disabling the unit tests on some platforms runs the risk to not cover=20
characteristics of that platform, BTW. Not ideal, is it. Ruining some=20
purpose of a CI.


TECHNOLOGIES WANTED FOR REDUCING UNIT TEST BUILD TIME

Enabling some kind of unity build for tests might be something nice to have=
=20
also IMHO. Because there cannot be enough tests usually, and Ruqola seems i=
n=20
a very healthy state here when it comes to coverage, at least by the number=
=20
of unit tests. Just exposing that way some badly scaling costs.

Personally would be interested into any technologies/approaches to merge=20
builds of unit tests, without affecting the actual test setups. By my pet=20
example Okteta, building the unit tests takes rougly half or more of the=20
time of building the actual product artifacts. A pain. And I would like to=
=20
have more tests there actually :)

Those into the Qt development world, would you know any related approaches,=
=20
when it comes to Qt testing frameworks? I'd be interested to explore this=20
actively together with others.

Cheers
=46riedrich