<div dir="ltr"><div dir="ltr">Hi, Ingo!<div><br></div><div>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.</div><div><br></div><div>Ideally, what we need is something like that:<br></div><div><br></div><div>1) CI builds: </div><div> * uses our custom deps built from 3rdparty folder<br></div><div> * builds unittests and static analyser </div><div> * built for every (bunch of) commit(s) </div><div> * built for linux (and, optionally, windows, osx, android)<br></div><div><br></div><div>2) MR builds: same as CI builds but</div><div><div> * builds an AppImage or a prebuilt docker image for testers</div></div><div> * built for each MR</div><div><br></div><div>3) Nightly builds:</div><div> * uses our custom deps built from 3rdparty folder</div><div> * builds packages for linux, windows, osx, android<br></div><div> * builds nightly<br></div><div><br></div><div>4) Release builds:<br></div><div><div> * uses our custom deps built from 3rdparty folder</div><div> * builds packages for linux, windows, osx, android<br></div><div> * builds on request<br></div><div><br></div></div><div>5) Distribution builds (just to make sure distributions can build Krita in some (probably, unsupported) way)</div><div> * uses dependencies from the distributions</div><div> * some currently missing dependencies should be built somehow manually or installed from a custom repository<br></div><div> * builds unittests and static analyser <br></div><div> * builds nightly</div><div> * built for linux and freebds(?)</div><div><br></div><div>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.<br></div><div> </div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 9, 2023 at 6:14 PM Ingo Klöcker <<a href="mailto:kloecker@kde.org">kloecker@kde.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Donnerstag, 9. März 2023 14:20:59 CET Halla Rempt wrote:<br>
> Sorry for the delay... Here's my first draft, please reply with suggestions<br>
> and corrections.<br>
<br>
I may be misunderstanding your needs, but I think Craft solves the problem of <br>
dependencies in that it can (and does) rebuild most dependencies if needed. <br>
(Some, like the compilers, are taken from the distribution and baked in the <br>
the CI images.) Craft also features patching. And it features a build artifact <br>
cache which speeds up rebuilds with all dependencies. Craft isn't used for <br>
Linux or FreeBSD builds (as far as I know), but using it also for those builds <br>
is technically no problem (and it is used for AppImage builds which except for <br>
the packaging are Linux builds). Craft currently doesn't run unit tests (or <br>
does it for Windows builds?), but that can be added easily.<br>
<br>
The upcoming switch from binary factory to GitLab CI for all Craft-based <br>
builds (which will hopefully be completed in the not-too-distant future; the <br>
signing of artifacts being one of the last missing things) will give you the <br>
possibility to build, package and publish any branch (main/master, release <br>
branches, work branches).<br>
<br>
Regards,<br>
Ingo<br>
<br>
> -------------<br>
> The situation: Krita has a lot of *complicated* and *new* dependencies. Some<br>
> dependencies need to be patched if the result is to be a working Krita, and<br>
> some aren't available on distributions yet. We're also moving quite fast<br>
> when it comes to updating and fixing dependencies -- and even upstreaming<br>
> fixes.<br>
> <br>
> This gives the following problem:<br>
> <br>
> * Jenkins CI depends, afaik, on distribution packages for dependencies.<br>
> While it's important that Krita builds on distributions, that doesn't<br>
> produce a version of Krita or a unittest run that works for Krita<br>
> developers. * We need a CI that builds against our dependencies so we can<br>
> have artefacts and unittest runs that represent our intention. * And we<br>
> also still need release and nightly builds, not just builds after merging<br>
> an MR<br>
> <br>
> I'm not sure how we can solve the problem of missing or outdated<br>
> dependencies on distribution CI: should we make an external cmake project<br>
> that builds those as part of the main build system? -------------<br>
<br>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Dmitry Kazakov</div></div>