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

[Ben Cooksley]

On Sat, Jul 18, 2026 at 4:33 AM Volker Krause <vkrause at kde.org> wrote:

> On Donnerstag, 16. Juli 2026 15:47:23 Mitteleuropäische Sommerzeit
> Friedrich
> W. H. Kossebau wrote:
> > DEPLOY STAGE "TESTS"
> >
> > When it comes to "Excessive tests" could we please also consider to make
> for
> > master/development/MR branches the "Deploy" stage on-demand, instead of
> > always running it together with the "Build" stage? That would scale
> across
> > all apps. And by my rough estimate by some samples I looked at save half
> of
> > those projects' CI time. And most activity happens on
> master/development/MR
> > branches, so this would scale even more.
> > For release branches always running the deploy stage seem reasonable,
> there
> > one wants to properly check everything as early as possible for
> regressions.
>
> For work branches and MRs this is basically already the case. CD jobs
> there
> only run when files likely relevant for those jobs change, ie. changing
> the
> Flatpak manifest as part of an MR also runs the Flatpak CD job but not the
> APK
> ones, while a pure code change wont run any of them.
>
> It's heuristics based on simple file name patterns, so there will be
> imperfections, but generally this does work.
>
> > From what I understand, those package builds (on master/development/MR
> > branches) are just done to test if packaging still works. So a plain test
> > run, just on package level. Taking roughly the full time of the normal
> > build. Sometimes even (much) longer, despite not building also normal
> (unit)
> > tests and running them.
> >
> > I very doubt that the resulting package artifacts on those branches are
> > actually used by anyone on a regular basis. There is no official CD
> also, is
> > there? (Nothing related spotted on apps.kde.org or heard about). So it
> > seems just a "does it package" test. With massive resource usage tag,
> > outnumbering any normal unit tests.
>
> That might be the case for some applications, for others those are very
> actively used and the main pillar of QA (see also my upcoming Akademy talk
> on
> this). I'd very much like to keep automatic CD builds on master for those
> cases. This doesn't mean this couldn't be an opt-out or opt-in option
> though.
>
> That being said, reviewing CD jobs for entirely unused ones and dropping
> those
> IMHO makes sense, they also cause cost during "horizontal" maintenance
> tasks
> like updating Android or Flatpak SDKs.
>

There are a significant number of applications that have added CD builds
yet don't take any action to publish the results of those as official
released builds (ie. on download.kde.org or the respective platform store).
That means outside of the occasional person downloading the nightly from
cdn.kde.org it is unlikely those CD builds are really being used - which is
quite a sad use of CI resources.

The ones on download.kde.org are: KDE Connect, Haruna, Crow Translate,
RKWard, Kdenlive, Krita, GCompris, KDiff3, Digikam, Labplot, Glaxnimate.
Our F-Droid repository has Elisa, Itinerary, Kalm, Kasts, Kongress, KTrip,
Neochat, Telly Skout and Tokodon. There will be others on the Play Store
and Windows Store.

Those projects that aren't taking steps to make builds available through
official channels (the cdn.kde.org nightly builds don't count) shouldn't
really have the CD build for that platform enabled really.


>
> Regards,
> Volker
>

Cheers,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20260718/7c09ff6e/attachment.htm>