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

[Volker Krause]

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.

Regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 232 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20260717/81ce6f0f/attachment.sig>