Draft for mail about ci

[Dmitry Kazakov]

Hi, Ingo!

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.

Ideally, what we need is something like that:

1) CI builds:
    * uses our custom deps built from 3rdparty folder
    * builds unittests and static analyser
    * built for every (bunch of) commit(s)
    * built for linux (and, optionally, windows, osx, android)

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

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

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

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(?)

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.




On Thu, Mar 9, 2023 at 6:14 PM Ingo Klöcker <kloecker at kde.org> wrote:

> On Donnerstag, 9. März 2023 14:20:59 CET Halla Rempt wrote:
> > Sorry for the delay... Here's my first draft, please reply with
> suggestions
> > and corrections.
>
> I may be misunderstanding your needs, but I think Craft solves the problem
> of
> dependencies in that it can (and does) rebuild most dependencies if
> needed.
> (Some, like the compilers, are taken from the distribution and baked in
> the
> the CI images.) Craft also features patching. And it features a build
> artifact
> cache which speeds up rebuilds with all dependencies. Craft isn't used for
> Linux or FreeBSD builds (as far as I know), but using it also for those
> builds
> is technically no problem (and it is used for AppImage builds which except
> for
> the packaging are Linux builds). Craft currently doesn't run unit tests
> (or
> does it for Windows builds?), but that can be added easily.
>
> The upcoming switch from binary factory to GitLab CI for all Craft-based
> builds (which will hopefully be completed in the not-too-distant future;
> the
> signing of artifacts being one of the last missing things) will give you
> the
> possibility to build, package and publish any branch (main/master, release
> branches, work branches).
>
> Regards,
> Ingo
>
> > -------------
> > The situation: Krita has a lot of *complicated* and *new* dependencies.
> Some
> > dependencies need to be patched if the result is to be a working Krita,
> and
> > some aren't available on distributions yet. We're also moving quite fast
> > when it comes to updating and fixing dependencies -- and even upstreaming
> > fixes.
> >
> > This gives the following problem:
> >
> > * Jenkins CI depends, afaik, on distribution packages for dependencies.
> > While it's important that Krita builds on distributions, that doesn't
> > produce a version of Krita or a unittest run that works for Krita
> > developers. * We need a CI that builds against our dependencies so we can
> > have artefacts and unittest runs that represent our intention. * And we
> > also still need release and nightly builds, not just builds after merging
> > an MR
> >
> > I'm not sure how we can solve the problem of missing or outdated
> > dependencies on distribution CI: should we make an external cmake project
> > that builds those as part of the main build system? -------------
>
>

-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20230309/a4910e1f/attachment.htm>