KDE Gear projects with failing CI (master + stable) (30 September 2025)

[Ben Cooksley]

On Thu, Oct 2, 2025 at 8:37 AM Ingo Klöcker <kloecker at kde.org> wrote:

> On Mittwoch, 1. Oktober 2025 19:58:54 Mitteleuropäische Sommerzeit Ben
> Cooksley wrote:
> > On Thu, Oct 2, 2025 at 1:35 AM Ingo Klöcker <kloecker at kde.org> wrote:
> > > On Mittwoch, 1. Oktober 2025 12:25:17 Mitteleuropäische Sommerzeit Ingo
> > > Klöcker wrote:
> > > > On Mittwoch, 1. Oktober 2025 12:12:43 Mitteleuropäische Sommerzeit
> Ingo
> > > > Klöcker wrote:
> > > > > But the actual problem is that kalarm 25.08 has this in its
> > > > > .craft.ini:
> > > > > ```
> > > > > kde/pim.version=master
> > > > > ```
> > > > >
> > > > > That's a general problem we have with the stable (PIM) builds. We
> > > > > might
> > > > > need something like the @same we use in .kde-ci.yml also for our
> craft
> > > > > CI builds.
> > > >
> > > > This should fix the problem:
> > > > https://invent.kde.org/pim/kalarm/-/pipelines/1051844
> > >
> > > New problem: Thanks to overzealous dependency bumping kalarm from the
> > > release/25.08 branch wants PIM deps of version 6.5.2 but 25.08.2 is not
> > > yet in
> > > craft.
> > > https://invent.kde.org/pim/kalarm/-/jobs/3423571
> >
> > Do you think we can revert that version bumping that was done across PIM
> /
> > make the dependency checks not so strict?
>
> Unfortunately, we have conflicting needs. Since PIM makes no source
> compatibility claims not even for release branches it makes sense that all
> 25.08.2 tarballs of PIM require all of their PIM dependencies to match
> 25.08.2. But the version bumping could happen quite a bit later. For
> 25.08.2
> the required versions of the PIM projects were bumped on 15 September to
> 25.08.2 although the tagging of 25.08.2 doesn't happen before 6 October.
> To
> minimize the disruption it would be good if the required versions were
> bumped
> maybe 2 days before the tagging instead of 20+ days before the tagging.
> Then
> it would "only" be about five days (from bumping to release) that Craft
> builds
> of PIM projects are broken.
>

That would be a good initial fix to start with yes.


>
> Better solutions would be:
> * The release branches of PIM stay source compatible, i.e. the release
> branches of PIM projects would require the .0 versions of the release
> instead
> of the latest minor versions. Since minor versions are bug fix releases I
> see
> little reason for source incompatible changes. Maybe something to discuss
> at
> the upcoming PIM sprint.
>

Within a release series i'd imagine we're likely largely already in this
space as adding new API to a stable release would be fairly uncommon i'd
hope?


> * We build release tags instead of release branches with Craft. Since CI
> would
> still test the release branches of all projects there should be little
> risk
> that the Craft builds break. Building tags is currently not possible with
> our
> CI tooling and Craft.
>

In this instance we'd remove the stable branch builds and only have the
release tag builds?

Supporting building on tags means needing to mark tags as protected within
Gitlab (to allow access to the signing infrastructure, etc).
Originally when Gitlab CI was rolled out that meant Gitlab would restrict
creation of tags to those with the maintainer role (so in practice that
would mean Sysadmin only) which is impractical.

Since then there have been changes though which mean that should no longer
be an issue however we would need to:
a) Validate our existing CI scripts for running in publishing mode on tags
(should be safe in theory but needs to be validated)
b) Publish tag protection rules to all mainline repositories

[image: image.png]

This would also mean that much like protected branches, developers would be
forbidden by Gitlab from removing a tag once it has been created and would
need Sysadmin to remove any mistakenly created tags.

* Building release branches of PIM with Craft instead of building the
> release
> branch of a PIM app against the released tarballs (or master) of its PIM
> dependencies. I think that currently not possible with Craft.
>

If Craft is able to produce cached build artifacts, then we should be able
to publish them for re-use without too much hassle on storage.kde.org
(utilising the token service to handle authentication).
I know Craft can generate build artifacts for tarballs, just not sure
whether it is able to do them for source builds.

It is on my list to explore migrating our existing Craft cache to
storage.kde.org from its current home on files.kde.org, and provision a CDN
endpoint for storage.kde.org for potential high request users to utilise.


>
> Regards,
> Ingo
>

Thanks,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20251003/41f2560c/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 42935 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20251003/41f2560c/attachment-0001.png>