Draft for mail about ci

[Ingo Klöcker]

On Donnerstag, 9. März 2023 17:52:20 CET Dmitry Kazakov wrote:
> I think the problem is not in the specific tool we use (it is possible to
> implement with any build system, including the upcoming GitLab). The
> problem is that we need quite an extensive build matrix, and we are
> wondering if KDE can actually host all that? We heard multiple times from
> sysadmins that build times and build variety might be a problem.

The main problem is rebuilding things again and again that don't need 
rebuilding. That's where Craft's cache can help.

> Ideally, what we need is something like that:
> 
> 1) CI builds:
>     * uses our custom deps built from 3rdparty folder

If you move the 3rdparty folder to a separate repo, then you'd get automatic 
rebuilds of the dependencies for free. Of course, you will lose the baked-in 
coupling to 3rdparty. Using Craft's blue print approach may be even better.

>     * builds unittests and static analyser
>     * built for every (bunch of) commit(s)
>     * built for linux (and, optionally, windows, osx, android)

Check (for GitLab CI).

> 2) MR builds: same as CI builds but
>     * builds an AppImage or a prebuilt docker image for testers
>     * built for each MR

Check.

> 3) Nightly builds:
>     * uses our custom deps built from 3rdparty folder
>     * builds packages for linux, windows, osx, android
>     * builds nightly

Builds with a fixed schedule are a bit of the problem because they may not be 
necessary if nothing changed in the last 24 hours. That may not be an issue 
for an actively developed application like Krita. In any case, GitLab supports 
scheduled builds even if we don't use them currently as far as I know.

> 4) Release builds:
>     * uses our custom deps built from 3rdparty folder
>     * builds packages for linux, windows, osx, android
>     * builds on request

That's what manual GitLab jobs give us.

> 5) Distribution builds (just to make sure distributions can build Krita in
> some (probably, unsupported) way)
>     * uses dependencies from the distributions
>     * some currently missing dependencies should be built somehow manually
> or installed from a custom repository
>     * builds unittests and static analyser
>     * builds nightly
>     * built for linux and freebds(?)

For some of this you might want to look into using the openSUSE Build Service. 
Despite the name it allows building packages for many distributions. This 
could be less work than maintaining your own set of Docker images for building 
Krita for the different distributions.

> Technically, it is possible to implement such layout within the feature set
> of GitLab. Though I'm not sure how many resources it would require.

If 3rdparty isn't rebuilt more often then necessary, then I'm sure GitLab will 
manage this. It survived many frameworks releases and Gear releases.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20230309/0098522e/attachment.sig>