KDE Gear projects with failing CI (release/24.02) (6 February 2024)

[Ben Cooksley]

On Thu, Feb 8, 2024 at 7:17 AM Friedrich W. H. Kossebau <kossebau at kde.org>
wrote:

> Am Mittwoch, 7. Februar 2024, 11:48:57 CET schrieb Ben Cooksley:
> > All of the Games Flatpak failures are caused by
> >
> https://invent.kde.org/games/libkdegames/-/commit/023d1a7b173f9d28453a0268e9
> > 1ad1ccb47054b9 I intend to revert that commit in 24 hours unless a
> suitable
> > explaination can be provided as to why 6.0.0 is actually required.
> >
> > All that commit has done is cause unnecessary breakage as I can't see
> > commits before or after it that justify that bump.
>
> The purpose of the commits (to libkdegames & libkmahjongg, actually
> planned to
> do for all of kdegames repos for consistency) has been to test that things
> still build  everywhere when the major version in the min required KF
> version
> is changed (5.x to 6.x).
> As such major version number change has been the cause for issues in the
> past,
> as some logic relies on that number sometimes.
> So it felt better also tested with KF6 now before the 6.0.0 release
> (compare
> e.g. the struggles Plasma has had with its major version number-based
> logic
> recently).
>
> And while those commits are the trigger, the cause is the design flaw of
> the
> flatpak jobs on "CI", which now exclude KF from CI & CD on the development
> branches, restrict the use of KF API to released versions.
>
> To get things rolling again for now, I have reverted the two commits now,
> removing the trigger again.
>
> I hope people find a solution to that challenge
> they created here though, because this seems a bit the tail (packaging/
> delivery) wagging with the body (development).
>
> If things break somewhere over the major version number in the dep
> version, I
> can say I tried ;)
>

It's more a reflection of how Flatpak works where applications are built on
top of a runtime.

In our case, to avoid every single application needing to build every
single Framework (and wasting copious amounts of disk space not to mention
build CPU time in the process) we place Qt and KDE Frameworks in a runtime
so they can be shared.
For those curious as to how long it takes to build this runtime (excluding
QtWebEngine) see
https://invent.kde.org/packaging/flatpak-kde-runtime/-/jobs/1561108 - yes,
it takes 2 hours on one of our CI nodes to build. Not something that is
practical to build every time you build an application.

Craft also has a similar issue as by default it provides the latest
released version of dependencies unless that is otherwise explicitly
overridden. Using that override though that means it has to build the
dependencies you've overridden every single time it performs a build -
which is not an efficient use of resources. As such it should be used
sparingly, if at all, and only if absolutely needed.

In general the expectation is that KDE applications (which is what all
these continuous delivery pipelines are aimed at) aim to build as a minimum
requirement against the latest released versions of things not in their
release unit (such as Frameworks).
This also makes it easier for new contributors to "jump in" as they can use
the development packages shipped by their distribution rather than needing
to build the world first (which is going to put a new contributor off).

This is in line with the precedent set over the entire lifetime of our Qt 5
based releases, where Frameworks, Release Service and independently
released applications all had independent release schedules and version
schemes.

I appreciate that major version bumps can cause all sorts of breakage
though, i'm expecting some degree of breakage no matter how much we
pre-test.


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