Re: Flatpak jobs on KDE CI vs. continuous integration on main/master/devel branches
On Mon, Feb 5, 2024 at 4:28 AM Friedrich W. H. Kossebau wrote: > Hi, > > ((cc:kde-frameworks-devel for heads-up, replies please only to > kde-core-deve)) > > I hit the problem that when working on a repo which would like to use > latest > KF development state to integrate some new KF API just added in > cooperation > with that very repo wanting to use it, I cannot do so when someone had > added a > flatpak job on CI to that repo. > > Because with such flatpak jobs it seems they are limiting the available KF > version not to the current latest one, as expected for continuous > integration, > but some older (anywhere documented?) snapshot: > > "runtime-version": "6.6-kf6preview", > Please see https://invent.kde.org/packaging/flatpak-kde-runtime/-/tree/kf6 for what is in the KF6 preview. > > What can be done here to reestablish the old immediate continuous > integration > workflow? Where new APIs (also from KF) are instantly available? > With Flatpak new APIs were never instantly available - there has always been a delay as the Flatpak Runtime uses the most recent released version of our software. > > Right now this is a new extra burden which makes working on new features > with > KF and apps more complicated. Thus less interesting, and one/I would > rather > duplicate code in apps to get things done. > > Blocking latest KF API from usage also means less testing of that before > the > initial release. > Besides all the resource costs to create flatpaks on master builds by > default > every time, when those are usually not used by anyone anyway. > Those applications that have a hard dependency on features being added to Frameworks are not good candidates for making use of our Continuous Delivery systems i'm afraid. Both Flatpak and Craft based (Linux Appimages, Android APKs, Windows and macOS) CD jobs are best optimised for those applications that rely on the stable Frameworks releases. There are ways (in .craft.ini) to make newer Frameworks available, but that requires that the system recompiles that Framework each time you trigger a build and is therefore not recommended. Allowing those systems to use the "latest" artifacts of Frameworks would be a non-trivial exercise. > So, how to solve those problems? Did I miss something? > Could flatpak builds on master branches be made on-demand rather? > Cheers > Friedrich > Cheers, Ben
Re: KDE Frameworks with failing CI (master) (4 February 2024)
On Mon, Feb 5, 2024 at 1:26 AM Albert Astals Cid wrote: > Please work on fixing them, otherwise i will remove the failing CI > jobs on their 4th failing week, it is very important that CI is passing > for > multiple reasons. > > Good news: 3 repository has been fixed > > Bad news: 2 repositories are still failing, 3 new ones have started failing > > > baloo - 2nd week > * https://invent.kde.org/frameworks/baloo/-/pipelines/598254 > * FreeBSD tests are failing > > > kfilemetadata - 2nd week > * https://invent.kde.org/frameworks/kfilemetadata/-/pipelines/598257 > * FreeBSD tests are failing > This one has been debugged by Christoph and there is a pending MR to fix this. See https://invent.kde.org/frameworks/kfilemetadata/-/merge_requests/126 Caused by differences in the FreeBSD / Linux APIs and the newer versions of FreeBSD / ZFS being more strict on the input they're given for attribute names. (so yes, there was an actual bug here) > > kdav - NEW > * https://invent.kde.org/frameworks/kdav/-/pipelines/598256 > * davcollectionsmultifetchjobtest fails both in Linux and FreeBSD > > > ki18n - NEW > * https://invent.kde.org/frameworks/ki18n/-/pipelines/598258 > * Linux tests are failing > The Linux image was recently rebuilt, possibly caused by newer dependencies coming through. > > > kuserfeedback - NEW > * https://invent.kde.org/frameworks/kuserfeedback/-/pipelines/598260 > * flatpak is failing (the SDK needs updating?) > https://invent.kde.org/packaging/flatpak-kde-runtime/-/commit/ddfdb201e65cfebdd33323a6752ff5e5fc475001 https://invent.kde.org/packaging/flatpak-kde-runtime/-/jobs/1560506 Once that has passed, a rebuild of the flatpak-builder CI image will be needed, then that will be fixed. > > > Cheers, > Albert > Cheers, Ben
Re: KDE Frameworks with failing CI (kf5) (4 February 2024)
Am Sonntag, 4. Februar 2024, 13:34:09 CET schrieb Albert Astals Cid: > ki18n - NEW > * https://invent.kde.org/frameworks/ki18n/-/pipelines/598250 > * Linux tests are failing Was found yesterday to be due to iso-codes 4.16 -> https://invent.kde.org/frameworks/ki18n/-/merge_requests/108 (candidate for KF5 backport also, to fix the same there) Cheers Friedrich
Flatpak jobs on KDE CI vs. continuous integration on main/master/devel branches
Hi, ((cc:kde-frameworks-devel for heads-up, replies please only to kde-core-deve)) I hit the problem that when working on a repo which would like to use latest KF development state to integrate some new KF API just added in cooperation with that very repo wanting to use it, I cannot do so when someone had added a flatpak job on CI to that repo. Because with such flatpak jobs it seems they are limiting the available KF version not to the current latest one, as expected for continuous integration, but some older (anywhere documented?) snapshot: "runtime-version": "6.6-kf6preview", What can be done here to reestablish the old immediate continuous integration workflow? Where new APIs (also from KF) are instantly available? Right now this is a new extra burden which makes working on new features with KF and apps more complicated. Thus less interesting, and one/I would rather duplicate code in apps to get things done. Blocking latest KF API from usage also means less testing of that before the initial release. Besides all the resource costs to create flatpaks on master builds by default every time, when those are usually not used by anyone anyway. So, how to solve those problems? Did I miss something? Could flatpak builds on master branches be made on-demand rather? Cheers Friedrich
Re: KDE Frameworks with failing CI (kf5) (4 February 2024)
On 2024-02-04 13:34, Albert Astals Cid wrote: Please work on fixing them, otherwise i will remove the failing CI jobs on their 4th failing week, it is very important that CI is passing for multiple reasons. Good news: 9 repositories were fixed Bad news: 2 repositories are still failing, 1 repository is newly failing baloo - 2nd week * https://invent.kde.org/frameworks/baloo/-/pipelines/598247 * Tests fail on FreeBSD kfilemetadata - 2nd week * https://invent.kde.org/frameworks/kfilemetadata/-/pipelines/598249 * Tests fail on FreeBSD https://invent.kde.org/frameworks/kfilemetadata/-/merge_requests/126 ki18n - NEW * https://invent.kde.org/frameworks/ki18n/-/pipelines/598250 * Linux tests are failing Cheers, Albert
KDE Frameworks with failing CI (kf5) (4 February 2024)
Please work on fixing them, otherwise i will remove the failing CI jobs on their 4th failing week, it is very important that CI is passing for multiple reasons. Good news: 9 repositories were fixed Bad news: 2 repositories are still failing, 1 repository is newly failing baloo - 2nd week * https://invent.kde.org/frameworks/baloo/-/pipelines/598247 * Tests fail on FreeBSD kfilemetadata - 2nd week * https://invent.kde.org/frameworks/kfilemetadata/-/pipelines/598249 * Tests fail on FreeBSD ki18n - NEW * https://invent.kde.org/frameworks/ki18n/-/pipelines/598250 * Linux tests are failing Cheers, Albert
KDE Frameworks with failing CI (master) (4 February 2024)
Please work on fixing them, otherwise i will remove the failing CI jobs on their 4th failing week, it is very important that CI is passing for multiple reasons. Good news: 3 repository has been fixed Bad news: 2 repositories are still failing, 3 new ones have started failing baloo - 2nd week * https://invent.kde.org/frameworks/baloo/-/pipelines/598254 * FreeBSD tests are failing kfilemetadata - 2nd week * https://invent.kde.org/frameworks/kfilemetadata/-/pipelines/598257 * FreeBSD tests are failing kdav - NEW * https://invent.kde.org/frameworks/kdav/-/pipelines/598256 * davcollectionsmultifetchjobtest fails both in Linux and FreeBSD ki18n - NEW * https://invent.kde.org/frameworks/ki18n/-/pipelines/598258 * Linux tests are failing kuserfeedback - NEW * https://invent.kde.org/frameworks/kuserfeedback/-/pipelines/598260 * flatpak is failing (the SDK needs updating?) Cheers, Albert
