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

--nextPartD0FukoBITsisArkfFGFIJg
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"; protected-headers="v1"
From: Volker Krause <[email protected]>
To: [email protected]
Cc: [email protected]
Date: Fri, 17 Jul 2026 18:32:58 +0200
Message-ID: <[email protected]>
Organization: KDE
In-Reply-To: <[email protected]>
MIME-Version: 1.0

On Donnerstag, 16. Juli 2026 15:47:23 Mitteleurop=C3=A4ische Sommerzeit Fri=
edrich=20
W. H. Kossebau wrote:
> DEPLOY STAGE "TESTS"
>=20
> 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, the=
re
> one wants to properly check everything as early as possible for regressio=
ns.

=46or work branches and MRs this is basically already the case. CD jobs the=
re=20
only run when files likely relevant for those jobs change, ie. changing the=
=20
=46latpak manifest as part of an MR also runs the Flatpak CD job but not th=
e APK=20
ones, while a pure code change wont run any of them.=20

It's heuristics based on simple file name patterns, so there will be=20
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 (un=
it)
> tests and running them.
>=20
> 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=20
actively used and the main pillar of QA (see also my upcoming Akademy talk =
on=20
this). I'd very much like to keep automatic CD builds on master for those=20
cases. This doesn't mean this couldn't be an opt-out or opt-in option thoug=
h.

That being said, reviewing CD jobs for entirely unused ones and dropping th=
ose=20
IMHO makes sense, they also cause cost during "horizontal" maintenance task=
s=20
like updating Android or Flatpak SDKs.

Regards,
Volker

--nextPartD0FukoBITsisArkfFGFIJg
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iHkEABECADkWIQQAnu3FVHA48KjZ07R/lszWTRLSRwUCalpZOhsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMSwyLDIACgkQf5bM1k0S0kcTmgCgkHo0c8zDHicc760KbMJe
53x+yxkAn26rzT9eHyJY2zwBxml2ekzwUT0X
=VcJN
-----END PGP SIGNATURE-----

--nextPartD0FukoBITsisArkfFGFIJg--