<div dir="ltr"><div dir="ltr">On Thu, Oct 2, 2025 at 8:37 AM Ingo Klöcker <<a href="mailto:kloecker@kde.org">kloecker@kde.org</a>> wrote:</div><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mittwoch, 1. Oktober 2025 19:58:54 Mitteleuropäische Sommerzeit Ben <br>
Cooksley wrote:<br>
> On Thu, Oct 2, 2025 at 1:35 AM Ingo Klöcker <<a href="mailto:kloecker@kde.org" target="_blank">kloecker@kde.org</a>> wrote:<br>
> > On Mittwoch, 1. Oktober 2025 12:25:17 Mitteleuropäische Sommerzeit Ingo<br>
> > Klöcker wrote:<br>
> > > On Mittwoch, 1. Oktober 2025 12:12:43 Mitteleuropäische Sommerzeit Ingo<br>
> > > Klöcker wrote:<br>
> > > > But the actual problem is that kalarm 25.08 has this in its<br>
> > > > .craft.ini:<br>
> > > > ```<br>
> > > > kde/pim.version=master<br>
> > > > ```<br>
> > > > <br>
> > > > That's a general problem we have with the stable (PIM) builds. We<br>
> > > > might<br>
> > > > need something like the @same we use in .kde-ci.yml also for our craft<br>
> > > > CI builds.<br>
> > > <br>
> > > This should fix the problem:<br>
> > > <a href="https://invent.kde.org/pim/kalarm/-/pipelines/1051844" rel="noreferrer" target="_blank">https://invent.kde.org/pim/kalarm/-/pipelines/1051844</a><br>
> > <br>
> > New problem: Thanks to overzealous dependency bumping kalarm from the<br>
> > release/25.08 branch wants PIM deps of version 6.5.2 but 25.08.2 is not<br>
> > yet in<br>
> > craft.<br>
> > <a href="https://invent.kde.org/pim/kalarm/-/jobs/3423571" rel="noreferrer" target="_blank">https://invent.kde.org/pim/kalarm/-/jobs/3423571</a><br>
> <br>
> Do you think we can revert that version bumping that was done across PIM /<br>
> make the dependency checks not so strict?<br>
<br>
Unfortunately, we have conflicting needs. Since PIM makes no source <br>
compatibility claims not even for release branches it makes sense that all <br>
25.08.2 tarballs of PIM require all of their PIM dependencies to match <br>
25.08.2. But the version bumping could happen quite a bit later. For 25.08.2 <br>
the required versions of the PIM projects were bumped on 15 September to <br>
25.08.2 although the tagging of 25.08.2 doesn't happen before 6 October. To <br>
minimize the disruption it would be good if the required versions were bumped <br>
maybe 2 days before the tagging instead of 20+ days before the tagging. Then <br>
it would "only" be about five days (from bumping to release) that Craft builds <br>
of PIM projects are broken.<br></blockquote><div><br></div><div>That would be a good initial fix to start with yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Better solutions would be:<br>
* The release branches of PIM stay source compatible, i.e. the release <br>
branches of PIM projects would require the .0 versions of the release instead <br>
of the latest minor versions. Since minor versions are bug fix releases I see <br>
little reason for source incompatible changes. Maybe something to discuss at <br>
the upcoming PIM sprint.<br></blockquote><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* We build release tags instead of release branches with Craft. Since CI would <br>
still test the release branches of all projects there should be little risk <br>
that the Craft builds break. Building tags is currently not possible with our <br>
CI tooling and Craft.<br></blockquote><div><br></div><div>In this instance we'd remove the stable branch builds and only have the release tag builds?</div><div><br></div><div>Supporting building on tags means needing to mark tags as protected within Gitlab (to allow access to the signing infrastructure, etc). </div><div>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. </div><div><br></div><div>Since then there have been changes though which mean that should no longer be an issue however we would need to:</div><div>a) Validate our existing CI scripts for running in publishing mode on tags (should be safe in theory but needs to be validated)</div><div>b) Publish tag protection rules to all mainline repositories</div><div><br></div><div><img src="cid:ii_mg9n9dub0" alt="image.png" width="562" height="230"><br></div><div> </div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* Building release branches of PIM with Craft instead of building the release <br>
branch of a PIM app against the released tarballs (or master) of its PIM <br>
dependencies. I think that currently not possible with Craft.<br></blockquote><div><br></div><div>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 <a href="http://storage.kde.org">storage.kde.org</a> (utilising the token service to handle authentication).</div><div>I know Craft can generate build artifacts for tarballs, just not sure whether it is able to do them for source builds.</div><div><br></div><div>It is on my list to explore migrating our existing Craft cache to <a href="http://storage.kde.org">storage.kde.org</a> from its current home on <a href="http://files.kde.org">files.kde.org</a>, and provision a CDN endpoint for <a href="http://storage.kde.org">storage.kde.org</a> for potential high request users to utilise.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Regards,<br>
Ingo<br></blockquote><div><br></div><div>Thanks,</div><div>Ben </div></div></div>