Re: Deploy stage manually on master, unit test build time technologies (was: Re: Excessive tests in Ruqola [...])
Ben Cooksley <[email protected]> Sat, 18 Jul 2026 15:11:59 +1200
| Newsgroups | gmane.comp.kde.devel.general,gmane.comp.kde.devel.core |
|---|---|
| Message-ID | <CA+XidOHF6enJqO00V=GbHXaSfrdkmQ4AgSM2cXvt2knpfezvXg@mail.gmail.com> |
--00000000000003abf60656da0a7e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jul 18, 2026 at 4:33=E2=80=AFAM Volker Krause <[email protected]> wro= te: > On Donnerstag, 16. Juli 2026 15:47:23 Mitteleurop=C3=A4ische Sommerzeit > Friedrich > W. H. Kossebau wrote: > > DEPLOY STAGE "TESTS" > > > > When it comes to "Excessive tests" could we please also consider to mak= e > 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 hal= f > 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 th= e > 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 te= st > > 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 tal= k > 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 --00000000000003abf60656da0a7e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><span style=3D"background-color:transpare= nt">On Sat, Jul 18, 2026 at 4:33=E2=80=AFAM Volker Krause <<a href=3D"ma= ilto:[email protected]">[email protected]</a>> wrote:</span></div><div class= =3D"gmail_quote gmail_quote_container"><blockquote class=3D"gmail_quote" st= yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd= ing-left:1ex">On Donnerstag, 16. Juli 2026 15:47:23 Mitteleurop=C3=A4ische = Sommerzeit Friedrich <br> W. H. Kossebau wrote:<br> > DEPLOY STAGE "TESTS"<br> > <br> > When it comes to "Excessive tests" could we please also cons= ider to make for<br> > master/development/MR branches the "Deploy" stage on-demand,= instead of<br> > always running it together with the "Build" stage? That woul= d scale across<br> > all apps. And by my rough estimate by some samples I looked at save ha= lf of<br> > those projects' CI time. And most activity happens on master/devel= opment/MR<br> > branches, so this would scale even more.<br> > For release branches always running the deploy stage seem reasonable, = there<br> > one wants to properly check everything as early as possible for regres= sions.<br> <br> For work branches and MRs this is basically already the case. CD jobs there= <br> only run when files likely relevant for those jobs change, ie. changing the= <br> Flatpak manifest as part of an MR also runs the Flatpak CD job but not the = APK <br> ones, while a pure code change wont run any of them. <br> <br> It's heuristics based on simple file name patterns, so there will be <b= r> imperfections, but generally this does work.<br> <br> > From what I understand, those package builds (on master/development/MR= <br> > branches) are just done to test if packaging still works. So a plain t= est<br> > run, just on package level. Taking roughly the full time of the normal= <br> > build. Sometimes even (much) longer, despite not building also normal = (unit)<br> > tests and running them.<br> > <br> > I very doubt that the resulting package artifacts on those branches ar= e<br> > actually used by anyone on a regular basis. There is no official CD al= so, is<br> > there? (Nothing related spotted on <a href=3D"http://apps.kde.org" rel= =3D"noreferrer" target=3D"_blank">apps.kde.org</a> or heard about). So it<b= r> > seems just a "does it package" test. With massive resource u= sage tag,<br> > outnumbering any normal unit tests.<br> <br> That might be the case for some applications, for others those are very <br= > actively used and the main pillar of QA (see also my upcoming Akademy talk = on <br> this). I'd very much like to keep automatic CD builds on master for tho= se <br> cases. This doesn't mean this couldn't be an opt-out or opt-in opti= on though.<br> <br> That being said, reviewing CD jobs for entirely unused ones and dropping th= ose <br> IMHO makes sense, they also cause cost during "horizontal" mainte= nance tasks <br> like updating Android or Flatpak SDKs.<br></blockquote><div><br></div><div>= There are a significant number of applications that have added CD builds ye= t don't take any action to publish the results of those as official rel= eased builds (ie. on <a href=3D"http://download.kde.org">download.kde.org</= a> or the respective platform store).</div><div>That means outside of the o= ccasional person downloading the nightly from <a href=3D"http://cdn.kde.org= ">cdn.kde.org</a> it is unlikely those CD builds are really being used - wh= ich is quite a sad use of CI resources.</div><div><br></div><div>The ones o= n <a href=3D"http://download.kde.org">download.kde.org</a> are: KDE Connect= , Haruna, Crow Translate, RKWard, Kdenlive, Krita, GCompris, KDiff3, Digika= m, Labplot, Glaxnimate. Our F-Droid repository has Elisa, Itinerary, Kalm, = Kasts, Kongress, KTrip, Neochat, Telly Skout and Tokodon.=C2=A0<span style= =3D"background-color:transparent">There will be others on the Play Store an= d Windows Store.</span></div><div><br></div><div>Those projects that aren&#= 39;t taking steps to make builds available through official channels (the <= a href=3D"http://cdn.kde.org">cdn.kde.org</a> nightly builds don't coun= t) shouldn't really have the CD build for that platform enabled really.= </div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0p= x 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=C2=A0</div= ></div></div> --00000000000003abf60656da0a7e--