Fwd: Linking to Gitlab CD build results

[Halla Rempt]

----------  Forwarded Message  ----------

Subject: Linking to Gitlab CD build results
Date: donderdag 7 maart 2024, 10:55:04 CET
From: Ben Cooksley <bcooksley at kde.org>
To: kde-devel <kde-devel at kde.org>, informing about and discussing non-technical community topics <kde-community at kde.org>

Hi all,

For those that have been experimenting with the Craft Continuous Delivery
jobs on Gitlab, one of the many questions we've been receiving is how to
best link to those from your websites.

I'm happy to advise that going forward build results will now be published
for release branches on mainline repositories at
https://cdn.kde.org/ci-builds/. This location is fully scalable and can be
freely linked to for the purpose of offering downloads of nightly builds of
your projects.

One key thing to note is that because Craft includes an incrementing number
in the filename, you should link to the appropriate folder not the artifact
directly. Additionally, please note that any slashes in branch names will
be converted into dashes as part of the publishing process.

Because this service is only available for release branches and master on
mainline repositories, builds from personal forks, or from work branches on
our mainline repositories will not be published here.

Please note that this is not a home for permanent release builds. On making
a release projects should download the latest build results (either from
Gitlab directly or from cdn.kde.org/ci-builds/), validate them and then
release them the same as any other tarball artifact. Older builds may be
removed from cdn.kde.org/ci-builds/ on a periodic basis.

With regards to Android and Flatpak, those will not be covered by those
service. For Android builds, usage of our F-Droid repositories (at
https://cdn.kde.org/android/) is recommended, while for Flatpak it is
recommended to make use of the Flatpak repositories we publish at
https://cdn.kde.org/flatpak/. These mechanisms are being preferred for
these two as they are native to those two platforms (while Linux appimages,
Windows installers and macOS images do not have those delivery mechanisms
available).

Thanks,
Ben

-----------------------------------------